In the IT realm there is an old concept called “AAA Architecture” (AAA standing for Authentication, Authorisation and Accounting). Each of these has a specific objective, which I am ultra simplifying as following:
– Authentication: Element used as proof of identity (WHO)
– Authorisation: Element used to define what is allowed to do (WHERE)
– Accounting: Reporting element (WHAT/WHEN)
When thinking about Email Authentication (generic term for DMARC, SPF and DKIM), I always flashback to my “data and communications” roots and visualise these, as a modern flavour (with extra vinaigrette) of the classic AAA.
Let’s say AAAP-Email (Authentication, Authorisation, Accounting and Policy in Email) is a brand for which its IT Team has great esteem and so, they definitely do not want others using it for wrongful purposes. To mitigate the risk of its “aaap.email” domain being used for phishing it has been implemented an AAAP configuration for it. That’s what I’m going to talk about in detail.
What are DKIM, SPF and DMARC and what’s their objective?
DomainKeys Identified Mail would be a TXT record under the domain’s DNS:
Which through mathematics does verify that the message was processed by WHO (says it was) using the domains “secret” part and that it remains intact:
“—–BEGIN RSA PRIVATE KEY—–
—–END RSA PRIVATE KEY—–“
(Oh yes, although I love maths, I am so glad this is done by machines! 🙂
DKIM signs the message which lets the endpoint validate authenticity as well as its integrity. It uses a mathematical relationship between very long numeric components, one which is publicly announced on a DNS record and the other, tightly protected (“secret”) and known only to the sender.
Is an Entity’s public statement (again through a DNS record) of which IPs are allowed to send messages.
Technically, sender Policy Framework is yet another DNS record, with the IPs allowed to send emails (WHERE) from “aaap.email”, in this specific case, only the domain’s mailservers (mx) as follows:
“v=spf1 mx -all”
Please note that SPF is the eldest of them all and so, it includes its own basic policy statement as well; the “-all” means its failure and “~all” it is considered only a soft fail (as It might be still some testing).
Accounting/DMARC: Domain-based Message Authentication, Reporting & Conformance states WHAT should be done to messages that fail authentication and/or authorisation (DKIM/SPF), as well as when and to whom the reports of WHAT happened coming from the domain should be sent and how often.
“v=DMARC1; p=reject; rua=mailto:email@example.com; ruf=mailto:firstname.lastname@example.org; rf=afrf; pct=100;”
The extra dressing is that DMARC declares a Policy for SPF and/or DKIM non-observance in messages.
Now if any nasty subject tries to use the domain and sends spoofed (good old terms) messages for phishing impetus, the receiver’s email servers are going to request the domain’s DNS for all the elements it needs to verify if its is genuine and intact and if in fact, it comes from an authorised source and if a failure scenario occours, what actions should it take following the domain’s policy statement which means, in this case rejection. (indicated by p=reject; my policy is reject if it fails) and so, the risk is now smaller.
Those messages are not reaching anyone. This is one of the reasons why the manual configuration of DKIM, SPF and DMARC are so important. The brand itself will remain intact and consequently, reputable.