SPF, DKIM and DMARC: secure your business email

Why your mailbox alone is not enough

Several systems often send using your business address: your mail provider, website contact form, accounting software, newsletter service or ticket system. Seeing a message in your sent folder says little about whether the recipient can reliably associate it with your domain.

Without suitable safeguards, the visible sender address is easy to impersonate. Authentication helps receiving systems distinguish authorised sending from certain forms of domain abuse. It does not establish whether an offer is trustworthy or an invoice is correct.

Three mechanisms share this task. DNS publishes your domain’s settings; the recipient performs the actual checks.

SPF: which servers may send for this domain?

SPF means Sender Policy Framework. A domain publishes a TXT record defining the systems allowed to send for it. The recipient compares the sending IP address with this policy.

The key detail: in ordinary email delivery, SPF checks the domain of the technical envelope sender, the SMTP address used for delivery feedback. This may differ from the visible From address. SPF passing alone therefore does not prove that the visible business address is authenticated.

Do not add another SPF policy at the same DNS name for each provider. Multiple SPF policies at that name are invalid. SPF also limits evaluated DNS-triggering mechanisms and redirects to ten; nested include references count. Technical reference: SPF standard RFC 7208.

In practice: combine the requirements of your actual sending services into one coordinated policy. Adding a service means reviewing the existing configuration, not automatically adding another TXT record beginning with v=spf1.

DKIM: which domain signed this message?

DKIM means DomainKeys Identified Mail. The sending service signs parts of a message with a private key. The recipient checks the signature using the public key in DNS, establishing whether the signed parts match and which domain takes responsibility.

The signature specifies a domain and a selector. The selector helps the recipient find the correct public key. Different services can use different selectors, so they need not share a key.

The private key stays with the signing system. It belongs neither in public DNS nor in a support message. Technical reference: DKIM standard RFC 6376.

In practice: enable DKIM at each sending service and publish exactly the DNS records it requests. Some providers require TXT records; others, such as Microsoft 365, use CNAME references. Microsoft documents its DKIM configuration here.

A DNS record alone is insufficient: check a real sent message to confirm that the service signs with your intended domain.

DMARC: does authentication match the visible sender?

DMARC means Domain-based Message Authentication, Reporting, and Conformance. It connects SPF and DKIM to the visible sender domain and provides a policy for failed checks.

To pass DMARC, at least one of these conditions must hold:

• SPF passes and the checked domain aligns with the visible sender domain.
• DKIM passes and the signing domain aligns with the visible sender domain.

This relationship is called alignment. Depending on the setting, the domains must match exactly or may belong to the same organisational domain. An spf=pass for an unrelated provider domain is not automatically enough. The same applies to a DKIM signature using only the provider’s domain.

Policies include none, quarantine and reject: request no special treatment solely because of this DMARC policy, request suspicious treatment or request rejection. The receiver still makes its own delivery decision. Reference: DMARC standard RFC 9989.

In practice: configure both mechanisms properly where possible. DMARC does not require both to pass simultaneously, but two correctly configured paths help with different sending and forwarding situations.

Step 1: list every sending route

Before changing DNS, build a sending inventory. It should be complete enough for your business.

Sending route	What to establish
Everyday mailboxes	Which provider sends mail and who manages its domain settings?
Website and contact form	Does WordPress send through the web server or a configured mail service?
Invoices and quotations	Which sender domain does the software actually use?
Newsletter	Is your domain verified and configured for DKIM?
Scanner, NAS and ticket system	Which SMTP account or relay is used?

Record the visible sender address, technical owner and current setup instructions for each service. Include infrequent tasks: month-end invoicing is easy to miss in a short test.

A common contact-form mistake is using the visitor’s address as From. Use a properly configured address of your own instead. The visitor’s address normally belongs in Reply-To so replies reach them. Your website cannot simply authenticate the visitor’s domain.

Step 2: check SPF and DKIM for each service

Save the existing DNS configuration as your working baseline. Consult each provider’s current documentation, change one traceable item at a time and record what changed.

For SPF, identify the envelope-sender domain and the permissions it needs. Some services handle this under their own domain. For DMARC, an aligned authentication path must still exist, for example DKIM using your domain.

For DKIM, enable signing, publish the required public records and wait for provider confirmation. Then send a real test message from that system.

DNS queries show the published configuration. Replace these reserved example names:

dig TXT werkstatt.example +short
dig TXT selector1._domainkey.werkstatt.example +short

selector1 is not universal. Use your provider’s selector; if CNAME is required, check that record too. Do not copy an entire SPF policy or DKIM key from an unrelated tutorial. Those values belong to your sending setup.

Step 3: start DMARC with reports

A starting point can be a policy with p=none and an address for aggregate reports. It allows observation without requesting quarantine or rejection through that policy. Other recipient filters remain active.

An illustrative example, not a configuration to paste unchanged:

DNS name: _dmarc.werkstatt.example
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@werkstatt.example

Replace the domain and destination address. The reporting destination must be configured and suitable for analysis. An external service under another domain may require additional DNS authorisation.

Aggregate reports summarise observed sending sources and authentication results. They are typically XML files, not a convenient list of individual messages. Not every receiver reports everything, so an absence of anomalies is not complete proof of delivery. RFC 9990 describes DMARC aggregate reporting.

Plan analysis before publishing the record: who reviews reports, investigates unfamiliar sources and contacts the sending-service owners? An unattended reporting mailbox mainly accumulates future work.

Step 4: fix errors and tighten the policy

Observe a period that covers your actual business processes. A fixed number of days cannot replace checking monthly invoices, newsletters and rarely used systems.

Investigate unusual sources. An unfamiliar IP may belong to a forgotten legitimate service or indicate unauthorised sending. Do not expand SPF merely because an address appears in a report. First establish who sends there and whether the route is needed.

Once all known legitimate routes produce correct results, introduce a stricter DMARC policy in a controlled way. Record the previous configuration, keep monitoring reports and delivery problems, and assign someone to make corrections. Switching to reject is an operational decision, not a final checklist tick.

How to inspect a test message

Send from each relevant system to an external mailbox you control. Open the complete message headers and find the authentication results added by the receiving provider. Arbitrary older header lines are not reliable evidence.

1. SPF: which domain was checked and did it pass?
2. DKIM: which domain signed and is the signature valid?
3. DMARC: does at least one successful mechanism align with the visible sender domain?

Test real business workflows too. Forwarding can break SPF because another server forwards the message. DKIM may survive if signed parts remain valid. Modified messages and mailing lists can produce different results.

What SPF, DKIM and DMARC do not solve

These mechanisms do not encrypt message content. They do not protect against every lookalike domain or an already compromised genuine mailbox. Account security, secure login and careful business processes remain necessary.

Passing checks does not guarantee inbox delivery either. Direct sending also needs a suitable server identity and working reverse DNS. See how to check PTR and reverse DNS.

Your next step: a complete sending inventory

Start with your service list and one test message from each system. Then check SPF and DKIM, establish a monitored DMARC reporting process and tighten the policy on that basis.

This creates a traceable mail operation you can maintain through your next provider change. Find short definitions in the glossary.