Implementing SPF, DKIM and DMARC

Anti-SPAM implementation covers filtering and blocking incoming spam on receiving and verifying the sender’s allowed hosts thus preventing the likelihood of your users becoming the target of a Joe job that will flood their inboxes with bounced mails when their email addresses are spoofed as the sender. Combination of SPF, DKIM and DMARC can be used as weightage to defining legitimate emails from spam.

SPF (Sender’s Policy Framework)

SPF requires cooperation of email hosts to add a SPF entry specifying allowed hosts that their domains will be sending emails from and also verifying incoming emails’ SPF records to ensure the sender is sending from a legitimate email server within the allowed IP or hostname listed in their SPF records.

It typically consist of a SPF TXT record specifying allow IP addresses ( or slash notation), mail servers of the domain (MX) or allowed hostnames (

The last part of the TXT is qualifier, an “all” with a prefix of +, -, ~, or ?.

+all = hard pass, allows all ip addresses to pass or specify a range to to pass which can streamlined to include allowed IP range. It is generally not used as receiving mail servers may queries and treat broad range allow as spammy or suspicious.

-all = hard fail, all hostnames or IP addresses not listed within the SPF records will be rejected

~all = soft fail, all hostnames or IP addresses not listed within the SPF records will be marked as suspicious but allowed through.

?all = allow, soft fail, all hostnames or IP addresses not listed within the SPF records will be allowed through (sending domain doesn’t enforces SPF)

DomainKeys Identified Mail (DKIM)

DKIM enabled servers signed outgoing messages using their private keys and receiving servers supporting DKIM will verify authenticity of email using public key of the sender’s DNS TXT/CNAME selector records. A signature tag within mail header, specifies the DKIM record to verify.

Microsoft 365 / Office 365 uses CNAME record type and selector1, selector2 as the tag but domain owner may also use additional DKIM record to specify signature used to sign emails sent from their in-house or mail hosting’s server.

Tags are usually a TXT record with tag and ._domainkey as hostname and public signature key as record. (e.g. with record as  v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyWwiExtkqSqTIyPzWExEZZllixUEgIJrwSF0HnmZALAnnYB+sam4ESuKym+wu6Prj6cat4LN34RswUja7JBCWIFnSre0Nzcw8s5SkIx50AhJ4M+i0/RY0bF9voZ/M6lOWzmixl8QDqGQoZTFumQaL0SvqCNfzEihNAgyO6uzusrT9X0dPwqx3vFF/jTpR3gVQCFj0Dr/Mk0K4oBngPcQW3lZOc9LJo177O9oqndw4y3XSZi9YqT+pDgEs4LAoOKtdaKVgS1hzfYUgTb6NZht9bbfV2pHwLdpHJtkaHqT557yXGCjHulrD50aXtlHhjPeyWgoqqdiVMEK2bRx3TGLswIDAQAB\;)

Adding DKIM for Microsoft 365 usually involves

  1. Adding CNAME selector1._domainkey and selector2._domainkey records pointing to and respectively. (e.g.
  2. Loggging to O365 admin center, under email authentication, DomainKeys Identified Mail (DKIM) –
  3. Click on Enabled for the required domain.


DMARC (Domain-based Message Authentication, Reporting & Conformance) may be defined along with SPF and DKIM records of a domain, adding domain name technical contact, published policies on handling of authentication errors, reporting and monitor protection of the domain from fraudulent email.

Example of a typical DMARC policy which p tags the default action to take. It is recommended to set p=none (to take no action) and monitor before enforcing with p=quarantine (mark as spam) or p=reject (reject the message).

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100; adkim=s; aspf=s

You can also specify how you want to align the result of DKIM and SPF in accordance with your requirements. (adkim=s or adkim=r, aspf=s or aspf=r, s specify strict adherence i.e. domain name must match while r specify a more relax approach which allows partial match i.e. subdomains are accepted as valid)