Procedure

Configure SPF, DKIM and DMARC for a domain

Configure SPF, DKIM, and DMARC using current standards by inventorying legitimate senders, publishing one minimal SPF record, enabling aligned DKIM, deploying DMARC with aggregate reports, and validating Authentication-Results.

Objective

Authenticate mail sent by a domain with a coherent SPF, DKIM, and DMARC design. Inventory every sender, build one maintainable SPF policy, enable DKIM on each platform, publish DMARC in monitoring mode, and validate alignment in messages that are actually received before enforcing a stricter policy.

Prerequisites

  • Administrative control of the domain DNS zone.
  • A complete list of senders including Microsoft 365, websites, CRM, newsletters, copiers, applications, and third-party services.
  • Access to each platform that must enable DKIM.
  • A mailbox or service for DMARC aggregate reports.
  • Test recipients at more than one mail provider so received headers can be compared.

Step-by-step procedure

1

Inventory every sending source

For each service, record the visible From domain, MAIL FROM or envelope domain, SPF IP/include mechanism, and DKIM signing domain. Include low-volume devices and monitoring applications because forgotten senders are a common cause of breakage when policies are tightened.

Expected result
  • Every sending source has an owner and a documented SPF/DKIM method.
2

Check the existing DNS records

Resolve TXT records for the domain and identify SPF, DMARC, and known DKIM selectors. Confirm that there are not multiple competing SPF or DMARC policies. Save the current state before editing the zone.

Resolve-DnsName -Type TXT <DOMAINE>
Resolve-DnsName -Type TXT _dmarc.<DOMAINE>
Expected result
  • The current configuration is documented and DNS conflicts are known.
3

Build one minimal SPF record

Merge legitimate sources into one SPF record. Use vendor-documented include mechanisms and remove obsolete senders. Monitor the number of DNS lookups generated by include, a, mx, and redirect mechanisms, and move from soft-fail to a stricter ending only after the sender inventory is reliable.

v=spf1 include:<FOURNISSEUR> ip4:<IP-AUTORISEE> ~all
Expected result
  • One valid SPF record covers all legitimate envelope senders.
4

Enable DKIM on every platform

Publish the DKIM records supplied by each provider and enable signing for the custom domain. Confirm that the d= signing domain aligns with the visible From domain at the alignment mode you intend to enforce.

Resolve-DnsName -Type CNAME <SELECTEUR>._domainkey.<DOMAINE>
Expected result
  • Messages from each important source return dkim=pass with an aligned signing domain.
5

Publish DMARC in monitoring mode

Start with a single DMARC record in p=none and configure aggregate reporting. Use monitoring data to find legitimate sources and alignment gaps before enforcement. If reports are sent to a third-party domain, confirm that the required external reporting authorization is in place.

v=DMARC1; p=none; rua=mailto:dmarc-reports@<DOMAINE>; adkim=r; aspf=r
Expected result
  • A single DMARC record is published and aggregate reports begin arriving.
6

Test messages that are actually received

Send from every important source to external mailboxes and inspect Authentication-Results, including spf, smtp.mailfrom, dkim, header.of dmarc, and header.from. Provider-side message tracing can help correlate what the sender emitted with what the recipient evaluated.

Expected result
  • Every legitimate flow achieves DMARC pass through aligned SPF or DKIM.
7

Correct unaligned senders

SPF pass does not satisfy DMARC if MAIL FROM is not aligned with the visible From domain. Likewise, DKIM pass can remain unaligned when only the provider domain signs. Configure custom bounce or signing domains offered by the SaaS platform.

Expected result
  • Business senders no longer depend on unaligned provider domains.
8

Strengthen DMARC gradually

After a representative monitoring period, move to quarantine and then reject only when legitimate sources are accounted for. Continue testing mailing lists and forwarding paths because they can alter SPF or DKIM behavior.

Expected result
  • Policy enforcement increases without blocking known legitimate senders.
9

Monitor future changes

Add email authentication to the onboarding checklist for every new SaaS or application. Do not authorize a new sender until its SPF/DKIM configuration and DMARC alignment are validated, and remove old authorizations when a service is retired.

Expected result
  • The configuration remains maintainable and reports reveal new or unexpected senders quickly.

Validation

The procedure is validated when:

  • Exactly one SPF policy exists and covers legitimate senders.
  • DKIM is active and aligned for the main sending platforms.
  • DMARC is published in monitoring or enforcement mode according to the approved rollout.
  • Received messages show coherent SPF, DKIM, and DMARC results in Authentication-Results.
  • Aggregate reports are monitored and included in the change process.

Rollback

  • Restore the previously documented SPF record if a critical sender was omitted, then correct the inventory.
  • Disable a broken DKIM configuration only on the affected platform while repairing it.
  • Return DMARC to p=none if stricter enforcement blocks legitimate traffic.
  • Keep aggregate reports so the effect of the rollback can be confirmed.

Troubleshooting / common errors

  • If SPF returns permerror, count DNS lookups and remove duplicate or obsolete mechanisms.
  • If DKIM passes but DMARC fails, check alignment between header.d and the visible From domain.
  • If forwarded mail fails SPF, confirm whether aligned DKIM remains valid before changing policy.
♡ 0