Email Security: DMARC, SPF and DKIM Setup

What are SPF, DKIM and DMARC, and how do they work together?

SPF is a DNS record listing which servers may send email on behalf of your domain (RFC 7208). DKIM adds a digital signature to every outgoing message using a key that belongs to your domain; the receiver checks the signature against the public key in DNS and knows the message was not altered in transit (RFC 6376).

Both leave a gap: neither protects the From address the user sees on screen. An attacker can produce valid SPF and DKIM with their own domain and still put your domain in the visible From address. DMARC closes that gap. It requires at least one of SPF or DKIM to pass and to align with the domain in the visible From header. As the domain owner you decide what happens to messages that fail (nothing, quarantine or reject), and receivers send you reports on what they did.

The DMARC standard was updated in May 2026: RFC 9989 replaced the old RFC 7489, and aggregate reporting is now defined in a separate document. The new version drops the “pct” tag and introduces a “t” tag for testing mode. We write your records to the new standard.

What happens without DMARC? A CEO fraud scenario

Take a 50-person import company. Its domain has an SPF record but no DMARC record. One Friday afternoon the accounts manager receives an email from the managing director’s exact address: the overseas supplier has changed bank accounts, and the outstanding invoice must be paid into the new account today. The address is right, the signature is right, the tone is familiar.

An email like this is usually sent not by breaking into a mail server but simply by forging the sender address (spoofing). On a domain whose DMARC policy is p=reject, large mailbox providers such as Gmail and Microsoft 365 reject the message before it reaches the inbox. On a domain without DMARC, the receiver’s own filter decides, and the message may well land in the inbox.

One limit should be stated plainly: DMARC only stops exact impersonation of your own domain. If the attacker registers a lookalike such as “companyname-tr.com”, DMARC cannot stop it. Against that kind of attack you still need a rule that payment changes are confirmed by phone, and staff who know what to look for.

How do you move a DMARC policy from p=none to p=reject?

Publishing DMARC straight at p=reject is the quickest way to block your own legitimate email. Most companies do not know exactly who sends email in their domain’s name: the CRM, the newsletter tool, invoices sent from the ERP, the website contact form, the HR platform, the photocopier’s scan-to-email feature. That is why the move is made in stages.

• Start with p=none and a rua address: no email is affected and reports are collected.
• Identify every sending source from the reports and set up SPF/DKIM alignment for each one.
• p=quarantine: failing messages go to the recipient’s spam folder, with the t=y test flag first if needed.
• p=reject: spoofed messages are rejected by the receiver.
• Set sp and np policies for subdomains and for non-existent or unused domains.

How do you read DMARC reports?

Receivers such as Gmail, Microsoft and Yahoo send daily aggregate reports in XML to the address in your rua tag. Each report shows which IPs sent how many messages in your domain’s name, whether SPF and DKIM passed, and the alignment result. Raw XML is tedious to read, so we feed the reports into an analysis tool and turn them into something readable.

In the first few weeks the reports usually hold surprises: a marketing tool nobody remembers, an old web server, a reseller sending from your domain. A decision is made for each source. If it is legitimate, it is authorised and DKIM signing is switched on; if not, it is left to be blocked.

What do the Google and Yahoo bulk sender requirements ask for?

Since February 2024, Google’s email sender guidelines have required anyone sending to personal Gmail accounts to use at least SPF or DKIM. Senders of 5,000 or more messages a day must have all three of SPF, DKIM and DMARC, align the From domain and offer one-click unsubscribe in marketing email; for these rules a DMARC policy of p=none is acceptable.

Yahoo’s sender best practices are similar: SPF and DKIM together, a valid DMARC record of at least p=none, and alignment. Mail that does not comply may go to spam or be rejected. For companies that send newsletters or bulk notifications, DMARC is now a deliverability issue as much as a security one.

What are the most common SPF, DKIM and DMARC mistakes?

The most common is an SPF record that exceeds the DNS lookup limit. Under RFC 7208, mechanisms that need a DNS lookup, such as include, may not total more than 10 during SPF evaluation. A record that gains another include for every new service becomes invalid at some point, and SPF fails outright. Having more than one SPF record on a domain also invalidates it.

The second is third-party services signing DKIM with their own domain. DKIM then passes but does not align, so it does nothing for DMARC. Signing with your own domain (custom DKIM) has to be enabled in the service’s control panel. If you use Microsoft 365, you need to enable DKIM for your domain rather than relying on the default onmicrosoft.com signature. If you are planning an Exchange to Microsoft 365 migration, the cleanest route is to build these records into the migration plan.

What you receive

• Inventory of every source that sends email in your domain’s name
• A single, cleaned-up SPF record within the lookup limit
• Aligned DKIM signing for every legitimate source
• Staged DMARC policy: none, quarantine, reject
• Protective records for subdomains and for domains that send no email
• DMARC report analysis and an end-of-period summary report

How we work

1. 1

   Free review

   We check the current SPF, DKIM and DMARC records on your domains and send you the gaps and risks in writing.

2. 2

   Monitoring mode

   DMARC is published at p=none with a reporting address; reports are collected without affecting mail flow.

3. 3

   Fixing the sources

   SPF and aligned DKIM are set up for every legitimate sending source seen in the reports, and sources you no longer use are removed from the record.

4. 4

   Gradual tightening

   As the reports come back clean, the policy moves to quarantine and then to reject.

5. 5

   Follow-up

   Records are updated when a new service is added, and reports are reviewed at regular intervals.

Frequently asked questions