As any mail administrator will know SPAM is rampant on the Internet. I’ve work in organizations where over 95% of all mail received at the perimeter is dropped as SPAM mail…
In previous blogs we have looked at the Sender Protection Framework (SPF) and DomainKey Identified Mail (DKIM). Now it is time to look at how we can extend on that and suggest to the receiving mail server what we’d like it to do when SPF and/or DKIM checks fail.
Author Domain Signing Practices (ADSP)
ADSP is a fancy name for a DNS TXT record that says what should a receiving server do if DKIM checks fail. The format of the DNS record is very straight forward there is just one tag/value pair as shown below
_adsp._domainkey.<email domain> TXT dkim=discardable
This would tell the receiving server to discard all mail that isn’t DKIM signed, or where DKIM checks fail. Other values for dkim= are
- all: where all mail for this email domain is signed by DKIM and it is up to the receiving server to decide what to do with this mail
- unknown: the default value where we are saying we can’t say for sure if mail for this email domain is signed or not
As you can see there isn’t much to ADSP and it also doesn’t give you too many options. ADSP has been marked as a historic standard now, and you’re really better of to look toward DMARC.
Domain-based Message Authentication, Reporting & Conformance (DMARC)
DMARC is a much more complete standard and gives you loads of options when configuring this policy. It is still a DNS TXT record (or set of records in the more complex cases). The official standard is RFC 7489
Summarizing the most pertinent parts of a DMARC record:
- adkim: Alignment mode for DKIM, where default r=relaxed (d can be the domain or the parent domain of the from address), or s=strict (d must match the domain of the from address)
- aspf: Alignment mode for SPF, where default r=relaxed (domain of mail from in SMTP can be the domain or the parent domain of the from address), or s=strict (domain of mail from in SMTP must match the domain of the from address)
- fo: Failure Option, where default 0=failure report if all fail, 1=failure report if any fail, 2=failure report if DKIM fails, and 3=failure report if SPF fails.
- p: Policy for this domain and all subdomains unless sp is also used, where default none=No specific action, qaurantine=Pass the mail but flag it or place it somewhere to make it look like suspicious mail, and reject=Reject the mail outright.
- pct: Percentage of emails (default 100) from this domain that have a DMARC signature attached.
- rf: Report Format, where default afrf=Auth-Failed Report Format is currently the only supported value.
- ri: Reporting Interval, where the value (default 86400 which is 1 day) is the number of seconds between aggregated reports, any other value than the default is on a best endeavors basis only.
- rua: Reporting URIs for Aggregated Reports. The address to send aggregated reports to.
- ruf: Reporting URIs for Failure Reports. The address to send message failure reports to.
- sp: Policy for all subdomains of this domain and all subdomains, where none=No specific action, qaurantine=Pass the mail but flag it or place it somewhere to make it look like suspicious mail, and reject=Reject the mail outright.
- v: Version which must be set to DMARC1 (in uppercase)
_dmarc.<email domain> TXT v=DMARC1;p=quarantine
Some examples for example.com
Reject all mail that fails either DKIM or SPF
_dmarc.example.com TXT v=DMARC1;p=reject;
Reject all mail that fails either DKIM or SPF and enforce a strict match on domains
_dmarc.example.com TXT v=DMARC1;adkim=s;aspf=s;p=reject;
Pass all mail but send failure reports to an example.com address, limit aggregated reports to 50MB
_dmarc.example.com TXT v=DMARC1;p=none;rua=mailto:firstname.lastname@example.org!50m;ruf=mailto:email@example.com;
Pass all mail but send failure reports to a contoso.com address, limit aggregated reports to 50MB
_dmarc.example.com TXT v=DMARC1;p=none;rua=mailto:firstname.lastname@example.org!50m;ruf=mailto:email@example.com;
example.com._report._dmarc.contoso.com TXT v=DMARC1
Notice how in this case we need a second DNS record to allow reports to be sent to a contoso.com address for an example.com DMARC policy
So as you can see DMARC is pretty powerful, however it is not yet widely used and we have seen issues when emails are auto-forwarded, e.g. Yahoo mail going to Office 365 and within Office 365 the recipient has set forwarding to their gmail account. The mail ends up in SPAM which is probably not the intention…