For example, I want to add two or more email addresses to SOA - hostmaster.domain.com and johndoe.gmail.com
If it is possible, how should it look like?
Also, can such email addresses in SOA like hostmaster#domain.com, or hostmaster.domain.com.johndoe.gmail.com break the DNS zone?
It is not possible, you can have only one email address encoded in a SOA record.
As for the second part, I do not know what you mean by "break the zone".
You need to have a valid SOA record, which means among other things changing the # for a . to encode the email address.
Related
Like many others, I have navigated the SPF/DKIM/DMARC world with some confusion.
About 4 weeks ago or so I finished setting everything (SPF/DKIM/DMARC) up correctly for a GoDaddy-hosted domain that uses Google's mailservers.
I set the _dmarc TXT record to take zero action with p=none and I used Postmark to monitor the results to see what was passing and failing over a week.
After a week or so I looked at the Postmark results and inserted the include: statements for the domains that I wanted to pass, but weren't. Then I waited another week to see the results. However, the results showed that the domains still weren't passing SPF or DKIM. Below is the SPF record, I've redacted parts of it that are revealing, but two of the domains are legit and still aren't passing.
v=spf1 include:_spf.google.com include:freshemail.io include:cherryroad.com ~all
Do I need to use the actual IP addresses in the include statements instead of the domains? Postmark lists these as well so that would be easy if so.
No, you shouldn't copy their IPs in there because they are subject to change, especially Google's.
If it's failing, presumably you have some results (usually in message headers) that tell you exactly which IP is failing, and you can track it down manually though those includes, do a reverse lookup on it, etc.
However, you're also using GoDaddy, which is mostly guaranteed not to work as they either block outbound SMTP or route it through their own servers, so you're very unlikely to get an SPF pass.
The issue was with SPF DNS lookup limits. I had no idea this was a thing and I'm amazed that this isn't mentioned anywhere on the documentation (whether that's Google's official documentation or otherwise) on setting up SPF/DKIM/DMARC, and didn't come up in Googling of this issue. This limit is designed to prevent denial of service attacks and infinite DNS loops.
For anyone else who sees this post
v=spf1 include:_spf.google.com include:freshemail.io include:cherryroad.com ~all
This SPF record actually has almost 15 DNS lookups, and the limit is 10 per domain. You can find out how many SPF DNS lookups your domain has with a service like AutoSPF or Easy DMARC
The solution, once you see your total DNS lookups, comes in four options:
Create subdomains and use those to diversify the records. For example using "email#business.mydomain.com" as the email for freshemail.io. Then on the SPF record for that subdomain, you would only have v=spf1 include:freshemail.io resulting in less than 10 DNS lookups for that domain.
As #Synchro mentioned, you don't want to use IPs because those can very well change, but the concept of using IPs instead of the domain names does essentially work because an IP address doesn't cost a DNS lookup. Check with the support/engineering of whatever service you're using, it's possible that they have an IP (or an IP range) that doesn't change often. You might be able to bring your DNS lookups under ten using this.
Note that Google takes up about 3 DNS Lookups, and you'll probably want to leave that one as the _spf.google.com value
Note that every SPF record also has a 255 character limit, so if you're using only IPs you'll need to break that up into a lot of SPF records probably
Use an SPF flattening or compressing service like AutoSPF. Essentially, these services employ method #2, but do some backend work every few hours to check and update the IP addresses associated with the domains. Then they provide you with a "compressed" record like v=spf1 include:_6359384.autospf.com ~all that references all of your records and results in far fewer DNS lookups.
Create your own method that acts kind of like #2 and #3, using GoDaddy's API and brew up something that performs updated lookups on a schedule/job and updates separate SPF records including all of the IPs.
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.
My DNS provider works perfectly for A records.
I am having great difficulty understanding the syntax of SPF records. I have no prior experience.
The DNS provider supports SPF records and it has two control boxes for information: 'Name' and 'SPF data'.
The A record which functions fine looks like this:
Name: potsandpins.info
IPV4 Address: 45.61.228.207
The SPF record which is giving me no joy looks like this:
Name: potsandpins.info
SPF Data: "v=spf1 a -all" (including the quotation marks)
My emails are received with a red flag in Gmail which says 'Gmail couldn't verify that potsandpins.info actually sent this message'.
Can anyone suggest anything as I've tried all sensible permutations?
You don't seem to currently have an SPF record for potsandpins.info maybe you deleted it because you ran into trouble. Anyway, think of the SPF as a whitelist of any IP addresses or hosts you've given permission to send email on your behalf.
The name would be either the root domain, sometimes designated by the #, or a hostname, foo, which you'd use if you were sending email out as example#foo.example.com.
The SPF data would be the version number (v=spf1), then mechanisms (e.g., a), and then the ip addresses or hosts you'd like to authorize, then the qualifier such as -ALL, which intends a hard fail. You may want to back off from that using ~ALL for now, which intends a softfail. I think it's better to be specific in SPF records as then they're easier to follow exactly what they're authorizing.
Here's an example SPF record. Let's say you wanted to authorize 192.0.2.10 and Google.
v=spf1 ip4:192.0.2.10 include:_spf.google.com ~all
Let's say you wanted to authorize a range of IP addresses and MailChimp:
v=spf1 ip4:192.0.2.0/24 include:servers.mcsv.net ~all
Here's a good article on common mistakes in SPF records.
Then it's important to validate your SPF record using a tool such as the SPF Survey. I like this tool because it gives more detailed, actionable error messages when there's a problem.
if you post the full headers of an example email and indicate any other services you use to send email, then it would be possible to provide more specific advice. For future reference, it's best to provide more details when you post to Stack Overflow as that makes it easier to help. I tried in this post but the information you provided limited how specific the answer could be.
Also, for future reference, it's best to post using example.com rather than a real domain name and use IP addresses from an IPv4 block reserved for documentation.
The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),
and 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation.
Anyway, I hope this helps.
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!
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