Why Email Authentication Matters
Email remains the primary attack vector for phishing, business email compromise (BEC), and ransomware delivery. In 2024, BEC attacks caused over $2.9 billion in losses globally, with Indian businesses increasingly in the crosshairs. The good news is that a significant proportion of these attacks exploit the fundamental weakness of SMTP — it was designed with no sender authentication mechanism. SPF, DKIM, and DMARC are the three DNS-based standards that, deployed together, close this vulnerability and protect your domain from being impersonated.
These three standards serve complementary roles: SPF authorises which mail servers can send email on behalf of your domain; DKIM provides a cryptographic signature that proves the email was not modified in transit; and DMARC ties them together with a policy that tells receiving mail servers what to do when authentication fails — and sends you reports so you can see what is happening to your domain's email.
SPF (Sender Policy Framework)
SPF works by publishing a TXT record in your domain's DNS that lists all IP addresses and mail server hostnames authorised to send email from your domain. A typical SPF record: v=spf1 include:spf.protection.outlook.com include:_spf.google.com ip4:203.0.113.50 ~all
Breaking this down: include:spf.protection.outlook.com authorises all Microsoft 365 mail servers; include:_spf.google.com authorises Google's mail servers; ip4:203.0.113.50 authorises a specific IP; ~all (softfail) marks unauthorised senders as suspicious but does not reject them — use this initially, then switch to -all (hardfail) once you are confident in your authorised sender list.
The most common SPF mistake is exceeding 10 DNS lookups. Each include:, a:, mx:, and ptr: mechanism counts as a DNS lookup. Exceeding 10 causes an SPF PermError, which many receivers treat as a fail. Use MXToolbox SPF Record Checker to count your lookups and flatten nested includes where necessary.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to outgoing emails. Your mail server signs outgoing emails with a private key; the corresponding public key is published in DNS. Receiving servers verify the signature against the public key, confirming the email content has not been tampered with in transit and that the signing domain authorised the message.
For Microsoft 365, enabling DKIM involves navigating to the Defender portal, selecting your domain, and enabling DKIM — M365 handles key generation and provides two CNAME records to add to DNS. For Google Workspace, you generate a DKIM key in the Admin Console and add the provided TXT record to DNS. Use 2048-bit RSA keys as a minimum; 4096-bit keys are preferable for new deployments.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC is the policy layer that ties SPF and DKIM together. It tells receiving servers what to do when an email fails SPF or DKIM authentication and provides an aggregate reporting mechanism that gives you visibility into all email being sent from your domain. A DMARC record is published as a TXT record at _dmarc.yourdomain.com. The recommended policy progression:
- Phase 1 — Monitor: p=none with rua reporting — No action on failing emails, receive aggregate reports. Run this for at least 30 days to understand all legitimate sending sources before making any policy changes.
- Phase 2 — Quarantine: p=quarantine with pct=25 — Send 25% of failing emails to spam. Increase pct incrementally as you validate no legitimate mail is failing authentication.
- Phase 3 — Reject: p=reject — Reject failing emails outright. This is the goal state that prevents direct-domain impersonation.
Reading DMARC Reports
DMARC aggregate reports (RUA) arrive as XML files compressed in ZIP attachments, typically once daily from major receivers (Google, Microsoft, Yahoo). They show which IP addresses sent email claiming to be from your domain, how many messages passed or failed SPF and DKIM, and whether the DMARC policy was applied. Use a DMARC reporting service like Dmarcian or Postmark DMARC to visualise this data rather than parsing raw XML.
Common findings in DMARC reports requiring action: marketing automation tools (Mailchimp, HubSpot, Zoho Campaigns) sending on your behalf without proper SPF or DKIM configuration; legacy on-premises mail relays not authorised in SPF; third-party services that send transactional email using your domain without proper authentication setup. PCCVDI Solutions has achieved p=reject for over 50 client domains, with the process typically taking 6–12 weeks from initial deployment of p=none monitoring to full rejection enforcement.