A web designer friend of mine is moving a customer of hers to a new hosting provider but she wanted me to look at their email setup to make sure that nothing she was doing would affect their email. I did an assortment of MX record and dns record lookups and to me there seems to be something really strange with their mail setup. For example, there are two mx records where I'm used to seeing one (domain names and ip addresses are dummy's just to be safe): Pref: 10 hostname: mx.name.net ip address: 111.222.555.333 and the second Pref: 20 hostname: mx.ct.diffname.net ip address: 111.222.444.222 and neither "name" nor "diffnam" is their domain name. Then the dns entry for mail.theirdomain.net points to an address that's different from either the two addresses pointed to by the mx record.
I haven't setup a mail server in a while but I checked the last one I did and in the mx record the hostname was mail.domainname.org (and there was only one entry) and the address in the mx record was the same as the address in the mail.domainname.org dns entry.
I could understand if there were two MX records for either load balancing or fail-over in case the main server went down but the setup seems strange and the fact that the mail.domainname.com dns entry doesn't point to the same address as the mx record makes me think something is setup wrong in their email system. Does anyone have some insight into this?
mail.domainname.com has nothing to do with MX or SMTP; it's just a normal domain name.
It typically points to an HTTP server that serves webmail, which may or may not be the same as the SMTP server.
The point of having multiple MX records is in case one of them goes down.
In a DNS zone file, there are different entries that denote the type of service for which a canonical may be directed. One of these is the MX record which determines where services look for email SMTP access. The primary record is called the A record, which usually directs to the IP address(s) for web services and the primary domain.
Hope this helps!
Related
Does the part of the email address that is to the left of the # symbol of an email address still count as part of the DNS? I've been told it doesn't, but surely it does - it must have it's own unique IP identifier of some sort.
Thanks,
For more details check email address, summarizing:
The format of email addresses is local-part#domain where the local part may be up to 64 characters long and the domain may have a maximum of 255 characters.
The left local-part of an email address doesn't count as a part of a DNS.
For the right side, the #domain:
The domain name part of an email address has to conform to strict guidelines: it must match the requirements for a hostname, a list of dot-separated DNS labels, each label being limited to a length of 63 characters and consisting
You could also check the RFC 2822 - 3.4.1. Addr-spec specification
Sending an email consists of two parts (its actually a little more complicated, but this is the simplified version - ignoring the local to internet part, and ports / encryption etc)
presuming you send an email to someone#example.com
Firstly, the domain name is looked up. example.com - the proces for that is that the configured DNS server is queried for an MX record. If the configured DNS server doesn't know, it will bounce the query up to the .com domain, to find who owns example.com from there it may get bounced up to the . root servers. Eventually, a response will come back that might look something like this
example.com. 300 IN MX 1 mx1.example.com.
example.com. 300 IN MX 2 mx2.example.com.
The mail server will then perform another lookup on mx1.example.com, this time obtaining the IP address.
It will then open a session to that IP address, and something like the following conversation will occur.
220 mx.example.com ESMTP n14si1330437wmh.246 - gsmtp
ehlo mail.example.com
250-mx.example.com at your service
mail from: me#example.com
250 … OK
rcpt to: test#example.com
250 … OK
So for the DNS portion of the process, the test# part is never used. A DNS server has no concept of an # in that context.
Once the DNS portion is completed, then the whole email address is used with the conversation to the mail server.
SO I went to put a new website live and got into my clients cpanel to change the a-record for the website - however it's a really weird set up - most of the records point back to the domain itself - and I know that changing the a-record will stop their email dead.
The first a-record points to a IP address - domainname.com - 111.222.333.444
A cname record: www.domainname.com points to domainname.com
A cname record: mail.domainname.com points to domainname.com
Then there's a text record (domainname.com) with the record: v=spf1 a mx ptr include:rhostbh.com ?all
Finally, in a different part of c-panel, there's the mx record that points to: domainame.com
Then there's a bunch more records that point to the same IP address as before, such as autoconfig.domainname.com and autodiscover.doamainname.com.
So the question is, how do I change the main a-records (domainname.com and www.domainname.com putting the new site live) without taking out the email?
Delete mail.domainname.com CNAME
Create A record:
mail.domainname.com A 111.222.233.244
Modify MX to point to mail.domainname.com
Wait for TTL to expire
Modify domainname.com as required
I have been reading this page on setting up SPF for my domain sending email through Amazon SES to my subscribers.
http://docs.aws.amazon.com/ses/latest/DeveloperGuide/spf.html
I have added the SPF as suggested :
"spf2.0/pra include:amazonses.com -all"
Afterwards it notes the following:
If you use "-all" as shown in the example above, ISPs may block email from IP addresses that are not listed in your Sender ID record. You therefore must add a record for every IP address that you send email from. As a debugging aid, you can use "~all" instead. When you use "~all", ISPs will typically accept email from IP addresses that are not listed. However, they may flag it. To maximize deliverability, use "-all" and add a record for each IP address.
All of my email is sent from my server for which I know the IP address. As such I want to setup a record for my servers IP - I am simply a little confused as to what I need to be using. Is it simply another record as follows:
"spf2.0/pra include:127.0.0.1 -all"
where 127.0.0.1 is replaced with my servers IP?
I have had a look at the openspf website with little success - a basic idea of what the correct record is would be great.
Thanks !
spf2.0/pra is SenderID syntax. While similar in name to SPF proper, they are different protocols. For an explanation of the differences and the controversy surrounding SPF vs. SenderID, check here.
for the SPF record syntax, check here. The most simple way to add your server to the record is as follows: "v=spf1 ip:xxx.xxx.xxx.xxx include:amazonses.com -all", where xxx.xxx.xxx.xxx should be replaced by your server's IP. Another option, if the A or MX record for your domain points to your mailserver's IP is: "v=spf1 a include:amazonses.com -all" or "v=spf1 mx include:amazonses.com -all". It's also allowed to add them all at the same time.
THE SITUATION:
I have ONE e-mail account per domain.
I use e-mails such as [some-alias]#[one-of-my-domains-name]. (server: mail.[mydomain]:[secure port]
My registrar (OVH) is different from my web host (Arvixe).
My hosting plan is a mutualised .NET hosting.
When I want to reply with one of my aliases, I use Mozilla Thunderbird 'Identities'. (Login = concrete domain mail account, FROM: 'the alias e-mail'.)
(And yes, this is very efficient to avoid getting spams and unwanted mailing lists.)
THE PROBLEM:
For some recipient using some spam protection services, I constantly get the error:
Remote server replied: 550 Blocked by SPF ()
HINTS/QUESTIONS AND IDEAS IN SEARCH FOR A SOLUTION
a friend said I have to configure the TXT spf record of my domain.
using different webmaster tools sites to get DIG info, I never get infos about the 'TXT' record. So I'm not sure: Should I edit this record on the side of my domain registrar or in the side of the hosting ?
Current on my registrar's side the record reads:
v=spf1 a:mail.[mydomain] include:mx.ovh.com ~all
and on my hosting's side it reads:
v=spf1 a:mail.[mydomain] ~all
THE BIG QUESTION:
How can I solve this ?
Thank you for your help
Your SPF record is a statement that the IP(s) sending the email are authorised to send email for your domain. In your case I am assuming you're actually sending through the Arvixe servers. The records should be set in the TXT record for your domain at the registrar (ovh).
So in this case you need at your registrar (ovh) to edit the TXT record for SPF to read:
v=spf1 mx a:mail.[yourdomain] include:spf.arvixe.com -all
Note: The modifiers on 'all' vary - +,-,~,? - and specify whether recipients should consider the tests conclusive and reject mail or not. There's a great (very thorough) howto on SPF here: http://www.zytrax.com/books/dns/ch9/spf.html
What is a bit unusual is that the recipients are rejecting what should be an inconclusive SPF record (e.g. default = accept). One of the core problems with email is that there will always be edge cases where recipient servers exhibit odd behaviour - I hope this helps in this case.
Solution found:
- I actually had to set the SPF or TXT (I set both at the same value) record on the hosting's side.
- I used check-auth#verifier.port25.com , which a mail service to checking if your e-mails are passing some anti-spam filter.
- The reply given by check-auth#verifier.port25.com made me understand the Source IP/HELO hostname were not mail.[mydomain] but [myhostingserversubdomain].arvixe.com here what my SPF and TXP spf records look like:
v=spf1 mx ptr:[thesubdomain].arvixe.com -all
(I think 'mx' is really not necessary in my case.)
EDIT : Slight improvement:
v=spf1 ip4:[[thesubdomain].arvixe.com IP] ptr:[thesubdomain].arvixe.com -all
mx removed since in my case the mx servers have nothing to do with it.
"ptr" requires DNS lookup, so I added the direct IP. I left "ptr" in case the IP changes (since it's managed by my host).
I have been asked to implement some email address validation on a web app - I'm sure we've all been there a thousand times... however, this time I have been asked to do an MX Lookup on the domain to see if it accepts emails.
Does anyone know of any potential problems with doing this? Is an mx lookup a reliable way of finding out if a domain accepts email? are there any edge cases where a valid email address could fail an MX lookup check?
Thanks for your advice!
are there any edge cases where a valid email address could fail an MX lookup check?
Yes, in that where there is no MX record, MTAs fall back to using the A record instead. So only allowing MX records would fail a class of mail servers that work in the real world.
Allowing any name with an MX or A record at least detects obvious mistypings that result in NXDOMAIN. However it will still allow mistypings that end up at squatter sites. A further step for addresses resolved by A records might be to check where port 25 is accepting connections on that address.
You can only check if there is an mail server registered for the domain.
If the server also accepts mails and if the address is valid (not syntactically but in the sense that there exists a inbox for it and so on...) you will only find out when sending the e.g. registration email
sample on how to do this in PHP
function mailserver_exists($email) {
list($user,$domain) = split('#',$email);
//included check for 'A' after [comment from bobince][1]
return checkdnsrr($domain,'MX') || checkdnsrr($domain,'A');
}
if(domain_exists('joe#foreigndomain.xx')) {...} else {...}
Yes you can use 'TinyTim#192.184.165.13' too. The PHP documentation for checkdnsrr(host, type) states
host may either be the IP address in
dotted-quad notation or the host name