# How to Set Up SPF, DKIM, and DMARC

- Link: https://offshorehosting.pk/set-up-spf-dkim-dmarc/
- Published: 2026-10-25T10:46:00+00:00
- Author: admin

# How to Set Up SPF, DKIM, and DMARC

If your invoices land in spam, or a customer reports a phishing email “from” your
domain that you never sent, the cause is usually missing or broken email authentication.
SPF, DKIM, and DMARC are three DNS records that together let receiving mail servers
verify that a message claiming to be from your domain really is from you.

They are not deliverability magic — passing all three does not guarantee the inbox—
but without them, mailbox providers have little reason to trust your mail at all.
Since February 2024, Google and Yahoo have required authentication from bulk senders,
and enforcement has tightened since. This guide explains what each record does, 
the order to set them up, and how to reach enforcement without blocking your own
legitimate mail.

## What each record proves

Each record answers a different question:

 * **SPF (Sender Policy Framework, RFC 7208)** lists the mail servers allowed to
   send mail for your domain. The receiver checks it against the envelope sender—
   the hidden Return-Path address — not the From line your recipient sees. If the
   sending server’s IP is not on the list, SPF fails.
 * **DKIM (DomainKeys Identified Mail, RFC 6376)** adds a cryptographic signature
   to each message. The receiver fetches the public key from DNS (at `selector._domainkey.
   yourdomain`) and checks the signature, proving the message was not altered after
   signing.
 * **DMARC (Domain-based Message Authentication, Reporting, and Conformance; RFC
   9989 as of May 2026, replacing RFC 7489)** ties the two to the visible From address.
   A message passes DMARC only if SPF or DKIM passes **and** the domain that passed
   matches — “aligns” with — the From domain. DMARC also tells receivers what to
   do with mail that fails, and where to send reports about it.

Alignment is the piece people skip. A newsletter tool may send your campaign with
its own bounce domain: SPF passes for the tool, not for you, so DMARC fails unless
the tool also signs with DKIM as your domain. A message can show SPF pass and DKIM
pass and still fail DMARC if neither authenticated domain aligns with the From domain.

## Before you publish anything: inventory your senders

The most common setup failure is forgetting a sender. Before touching DNS, list 
every service that sends mail as your domain:

 * Your email provider (Google Workspace, Microsoft 365, or your host’s mail server)
 * Your website’s contact forms and order notifications
 * Your CRM, helpdesk, and invoicing system
 * Your newsletter or marketing platform
 * Transactional mail services (password resets, receipts)
 * Any server or script that sends mail directly

Each one needs to be covered by SPF (authorised to send) or DKIM (signing as your
domain), or it will fail DMARC when you reach enforcement. This inventory is the
single most valuable step in the whole process.

## Step 1: Publish SPF

SPF is a TXT record at your domain root. A typical record looks like this:

    ```
    example.com.  TXT  "v=spf1 include:_spf.google.com include:spf.mailprovider.example -all"
    ```

The parts:

 * `v=spf1` identifies the record as SPF.
 * Each `include:` adds another provider’s authorised servers. Your email provider’s
   documentation gives you the exact value to include — use theirs, do not guess.
 * `-all` at the end means “fail mail from any server not listed”. The softer `~
   all` means “soft-fail” and is sometimes used during testing, but `-all` is the
   correct end state.

Rules that catch people out:

 * **Only one SPF record per domain.** Publishing two separate `v=spf1` records 
   breaks SPF. Merge all providers into a single record.
 * **The 10 DNS lookup limit.** SPF allows at most 10 DNS lookups (each `include:`
   counts). Providers that include other providers can burn through the limit quickly.
   If you exceed it, SPF returns an error and fails. Flattening includes or removing
   unused providers is the fix — check with a lookup-counting tool before publishing.
 * **SPF is checked against the Return-Path, not the From address.** If your marketing
   tool uses its own bounce domain, SPF will authenticate that domain, not yours—
   which is why DKIM alignment matters for DMARC.

## Step 2: Set up DKIM

DKIM works in two parts: a private key held by the sender, and a public key published
in DNS.

 1. Generate the key pair in your email provider’s admin console or your hosting panel.
    Most providers do this for you and show you the DNS record to publish. Google recommends
    2048-bit keys; 1024-bit is the minimum.
 2. Publish the public key as a TXT record at `selector._domainkey.example.com`, where`
    selector` is the name your provider gives you (for example, `google` for Google
    Workspace, or `s1`/`s2` for some transactional providers). The record looks like:
    `
    google._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."`
 3. Enable signing in the provider, and send a test message. Check the message headers
    in the recipient’s mailbox for a `DKIM-Signature` header and an Authentication-
    Results line showing `dkim=pass`.

Each sending service has its own selector and key. If you send through three services,
you will have three DKIM records, each under its own selector.

## Step 3: Publish DMARC in monitoring mode

DMARC is a TXT record at `_dmarc.example.com`:

    ```
    _dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
    ```

 * `v=DMARC1` identifies the record.
 * `p=none` is the policy: take no action on failing mail, just report it. This 
   is monitoring mode, and it is where everyone should start.
 * `rua=mailto:dmarc@example.com` is where aggregate reports go. Use a dedicated
   mailbox — reports arrive daily and the volume adds up.

Start at `p=none` and stay there for at least two to four weeks. The reports will
show you every source sending mail as your domain, including the ones you forgot
in your inventory, and whether each one passes or fails. Fix the legitimate senders
that fail — add a missing SPF include, enable DKIM signing, fix alignment — before
you tighten anything. Jumping straight to enforcement before reading any reports
is the single most common way to break legitimate mail.

## Step 4: Tighten the policy gradually

Once reports show your legitimate mail passing consistently, move to `p=quarantine`—
failing mail goes to spam — watch reports for another one to two weeks, then move
to `p=reject`, where failing mail is refused.

A stricter record looks like:

    ```
    _dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=r; aspf=r"
    ```

The `adkim` and `aspf` tags set alignment to relaxed (`r`, the default, where the
organisational domain must match) or strict (`s`, where the domain must match exactly).
Relaxed alignment is the usual choice. Forensic reports (`ruf`) give detail on individual
failures but are sent by only some receivers and can be voluminous — aggregate reports(`
rua`) are the essential ones.

## Why this matters for bulk senders

Google’s sender guidelines define a bulk sender as one sending around 5,000 or more
messages to personal Gmail accounts in 24 hours (counted across the primary domain
and its subdomains, and permanent once assigned). Bulk senders must authenticate
with both SPF and DKIM, publish a DMARC record of at least `p=none`, align the From
domain, support one-click unsubscribe on marketing mail, and keep spam complaint
rates below 0.3% (Google recommends staying below 0.1%). Non-compliant mail faces
temporary errors, spam placement, or rejection. Even if you never send bulk mail,
every sender needs SPF or DKIM, valid forward and reverse DNS, and TLS.

Note that authentication does not buy an inbox. RFC 9989 itself says a DMARC pass
only shows the domain was used with permission and “does not guarantee” delivery.
Complaints, sending habits, and reputation still decide the rest.

## Verifying your setup

After publishing each record, allow time for DNS propagation, then verify:

 * Query the records directly:
    `bash dig TXT example.com dig TXT google._domainkey.
   example.com dig TXT _dmarc.example.com
 * Send a test message to a mailbox you control and inspect the Authentication-Results
   header: you want `spf=pass`, `dkim=pass`, and `dmarc=pass` with alignment.
 * Use a free authentication checker (such as the tools run by DMARC report providers
   or mailbox providers) to confirm the records parse correctly.
 * Read your DMARC aggregate reports weekly at first. They are XML, so use a report
   parser or a DMARC monitoring service to make them readable.

## Common mistakes

 * **Two SPF records** instead of one merged record.
 * **Exceeding the 10-lookup SPF limit** through nested includes.
 * **A DKIM key generated but never published**, or published under the wrong selector.
 * **Going to `p=reject` on day one**, blocking a forgotten sender such as the website’s
   contact form.
 * **Forgetting a subdomain** that sends mail — each subdomain that sends needs 
   its own consideration, and DMARC policy can inherit from the organisational domain.
 * **Assuming the job is done.** New services get added, providers change their 
   sending infrastructure, and keys need rotation. Check the records and reports
   quarterly.

## Key takeaways

 * SPF authorises servers, DKIM signs messages, DMARC checks alignment with the 
   From domain and sets the policy.
 * Inventory every sender before publishing anything — the forgotten sender is the
   one that breaks.
 * One SPF record only, and watch the 10-lookup limit.
 * Start DMARC at `p=none`, read the reports, fix legitimate senders, then move 
   to quarantine and reject.
 * Authentication is the baseline for deliverability, not a guarantee of the inbox.

## Sources

 * RFC Editor, “RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance(
   DMARC)” — https://www.rfc-editor.org/info/rfc9989/
 * TrendInTech, “DMARC, SPF, and DKIM Setup: 13 Steps [2026]” — https://trendintech.
   com/dmarc-spf-dkim-email-authentication-setup-2026/
 * DMARCReport, “DMARC for Google Workspace and Gmail: Complete Setup Guide (2026)”—
   https://dmarcreport.com/blog/dmarc-gmail-google-workspace-complete-guide/
 * Overloop, “SPF, DKIM, DMARC: Cold Email Setup” — http://overloop.com/blog/spf-
   dkim-dmarc

## Sources

 * {‘title’: ‘RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance(
   DMARC)’, ‘url’: ‘https://www.rfc-editor.org/info/rfc9989/’}
 * {‘title’: ‘DMARC, SPF, and DKIM Setup: 13 Steps [2026]’, ‘url’: ‘https://trendintech.
   com/dmarc-spf-dkim-email-authentication-setup-2026/’}
 * {‘title’: ‘DMARC for Google Workspace and Gmail: Complete Setup Guide (2026)’,‘
   url’: ‘https://dmarcreport.com/blog/dmarc-gmail-google-workspace-complete-guide/’}
 * {‘title’: ‘SPF, DKIM, DMARC: Cold Email Setup’, ‘url’: ‘http://overloop.com/blog/
   spf-dkim-dmarc’}