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) – […]
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.
Contents
What are DKIM, SPF and DMARC and what’s their objective?
Authentication/DKIM
DomainKeys Identified Mail would be a TXT record under the domain’s DNS:
“v=DKIM1;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDV5OtEvd65r2LA2+qJBX3BmgbZw9ToHstygvbVIwv2N76NrJMq1d+C8KpXhC5EzO/3tKkKXNg8K3c1a8WQX4n1kkP7q5dcMyibBC209szXsLBoipr7G6nZFruE5cKTSQQ++4xuNzALWvtWeFnmOhfUdRWh693mFOvlX7j9ZId44wIDAQAB”
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—–
MIICXAIBAAKBgQDV5OtEvd65r2LA2+qJBX3BmgbZw9ToHstygvbVIwv2N76NrJMq
1d+C8KpXhC5EzO/3tKkKXNg8K3c1a8WQX4n1kkP7q5dcMyibBC209szXsLBoipr7
G6nZFruE5cKTSQQ++4xuNzALWvtWeFnmOhfUdRWh693mFOvlX7j9ZId44wIDAQAB
AoGAFZzB4PpGbQC5u7783cd+Q3eqxYoyExo5eGKfSj32UXSkfnA3lpZxtStYKuui
OTVz8dWBVxi2iK3jp7QyDDp7F/O8p6doEAWVYZyJe5SAMLQKrJ7x8bjzntkga35C
kPNlzSUvTACTxTf2JPedy97uvpVvqI7OrZ6Lls+XD8MwCiECQQD7VjI9qqb71L3h
7b4XlhYMhaEivOST0wu9unsEJiytsZjLzUIA/XTO5MyDKyvoFU+99kDSlCo0uZeJ
85ckg3vZAkEA2dzgsyKe4ohk1IDAmGZCrRUufEH1BGx/Ydi7YJCaBk1LEVf8DCU4
TpFItegoAacR5BzALpR74u7oWSOs1PARGwJBAK58huCc6tSGO1TwMjo5rhD/bICr
VpzxtYMARYr53aawVv2WAC6jx0YjPYAKpq62rOeaYCJRToPQHM5e2B03UvECQBQB
ZljMuw5OPAQPdqAH8+N06HncjKVFWUUg48PwQ1SE0HndPHXZDRyZ1rVthg7wyoHJ
6hPc6qtiCM/2qK49BTUCQDUSBxiOyanPw0d4GhGDh4QUcBDDsumyKwxnBNP1aF5t
VLT8LzzIWYiC7Zmfq3JfI0FidDr9vygPFE5VfRU7Q8E=
—–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.
Authorisation/SPF
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)
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:dmarc@aaap.email; ruf=mailto:forensic@aaap.email; rf=afrf; pct=100;”
The extra dressing is that DMARC declares a Policy for SPF and/or DKIM non-observance in messages.
Conclusion
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.