How To Set Up SPF DKIM And DMARC For A New Sending Domain

SPF, DKIM, and DMARC are the three DNS-based checks that prove your new sending domain is legitimate and help mailbox providers trust your mail instead of filtering it to spam. SPF is a TXT record that lists which systems are allowed to send for the domain, DKIM adds a cryptographic signature tied to a public key in DNS, and DMARC publishes a policy plus reporting addresses so receivers know what to do when authentication fails. The practical setup is making sure every sender is accounted for, keys are published under the right selector, and domain alignment matches the visible From address. The most common “everything looks right” failure is alignment, not the records themselves.

Domain and DNS prerequisites before publishing email authentication

Confirm domain ownership and DNS access

Before you touch SPF, DKIM, or DMARC, make sure you can actually edit DNS for the domain you plan to use. You need access to your DNS host (often your registrar or a DNS provider like Cloudflare) and permission to add or edit TXT records.

Do a quick inventory now:

Who controls the domain login and 2FA?
Where DNS is hosted (nameservers tell you this).
Whether there are existing SPF, DKIM, or DMARC records you must not overwrite.

If your domain is already sending any mail (Google Workspace, Microsoft 365, a website form, a CRM), changing DNS without mapping all senders can break deliverability. For a new sending domain in Mailscribe, you still want full DNS control so you can publish records cleanly and troubleshoot fast.

Choose the sending domain and From domain

Decide what recipients will see in the visible From address. In most setups, you want the From domain to match your brand domain (for example, you@yourcompany.com) because it builds recognition and supports alignment.

Next, decide whether you will send from:

Your root domain (yourcompany.com), or
A dedicated subdomain (mail.yourcompany.com or news.yourcompany.com).

A dedicated subdomain is often safer for new programs because it separates marketing or bulk sends from day-to-day mailbox traffic. It also makes it easier to isolate reputation and roll back changes.

Plan subdomains and alignment goals

Authentication is not just “records exist.” Receivers also check alignment, meaning SPF and/or DKIM must align with the visible From domain under DMARC rules.

Plan this up front:

If your From is @yourcompany.com, aim for DKIM signing with d=yourcompany.com (or decide if relaxed alignment is acceptable).
If you use news.yourcompany.com as the From, keep SPF, DKIM, and DMARC scoped consistently to that subdomain.

Write down every service that will send mail using this identity (Mailscribe, support desk, invoicing, CRM). You will use that list to build SPF includes and DKIM keys without missing a sender later.

SPF record setup for authorized sending sources

SPF syntax basics and common mechanisms

SPF is a DNS TXT record that tells receiving servers which IPs or services are allowed to send email for your domain. An SPF record always starts with a version tag, then mechanisms, and ends with a qualifier (usually a hard fail).

A typical SPF record looks like this:

v=spf1 include:spf.yourprovider.com -all

Common mechanisms you will actually use:

include: authorizes a vendor’s sending infrastructure (most common for platforms like Mailscribe).
ip4: and ip6: authorizes specific sending IPs you control.
a and mx: authorize the domain’s A record or MX hosts. Use these only when you truly send mail from those servers.

For most businesses, SPF should be a short list of includes plus -all. Avoid using +all (allows anyone) or leaving the record open-ended.

Including third-party senders without breaking SPF

SPF works best when you have one SPF TXT record per domain. Multiple SPF records can cause SPF to return “permerror,” which is effectively a fail for many receivers.

Instead of adding separate SPF TXT records for Mailscribe, Google Workspace, and a helpdesk tool, combine them into a single record with multiple includes, for example:

v=spf1 include:spf.mailscribe.com include:_spf.google.com include:spf.helpdeskvendor.com -all

If you are unsure whether a service needs SPF, check whether it sends using your domain in the envelope sender (return-path). Many tools do, and missing it can cause DMARC failures later.

Staying under the SPF 10-lookup limit

SPF has a practical constraint: receivers typically stop evaluating after 10 DNS lookups (includes, a, mx, redirect, and some exists checks count). Exceed that limit and SPF can fail even if everything is “correct.”

To stay under the limit:

Prefer fewer vendors, and remove old includes you no longer use.
Avoid a and mx unless necessary, since they can add lookups.
If a vendor offers a “flattened” SPF option or a smaller include, use it.
For complex environments, consider moving some services to a dedicated subdomain so each domain has a simpler SPF footprint.

DKIM signing setup and selector management

Generate DKIM keys in your sending platform

DKIM works by adding a digital signature to each outgoing message. Receivers verify that signature using a public key you publish in DNS. For a new sending domain, you will typically generate DKIM keys inside your sending platform, then copy the DNS record it gives you.

A few practical choices matter here:

Key length: If your platform supports it, prefer 2048-bit DKIM keys. Some older systems still use 1024-bit by default.
Selector: The selector is the “name” of the key. It appears in the DKIM-Signature header as s=.... Use a selector that is easy to rotate later, like s1 or 2026q1.
Signing domain (d=): Make sure the platform is configured to sign with the same domain you plan to use in the visible From address, or at least a domain that will align under your DMARC alignment mode.

Publish the DKIM public key in DNS

Your DNS record will be created at a hostname that looks like:

selector._domainkey.yourdomain.com

Platforms will ask you to add either:

A TXT record containing the public key (common), or
A CNAME record pointing to a vendor-managed DKIM record (also common and often easier to maintain).

Whichever method you use, be careful with formatting. DKIM keys are long, and some DNS interfaces wrap text automatically. If the platform provides the value split into multiple quoted strings, keep it exactly as provided. One missing character can cause consistent DKIM failures.

Also confirm you publish the record on the correct domain. A frequent mistake is adding DKIM for yourdomain.com while actually sending as news.yourdomain.com (or the other way around).

Rotating keys and managing multiple selectors

DKIM key rotation is normal. It limits risk if a key is exposed and keeps your setup maintainable as your sending program grows.

A clean rotation pattern looks like this:

Create a new selector (for example, move from s1 to s2) and publish the new DKIM record in DNS.
Switch your sending platform to sign with the new selector.
Keep the old selector published for a while so previously sent mail can still be validated during mailbox provider retries and forwarding.
Remove the old selector once you are confident it is no longer needed.

If you send through multiple systems, you may end up with multiple selectors on the same domain. That is fine. DKIM allows it. What matters is that each system signs consistently, and the selector it uses has a matching DNS record.

DMARC record setup and recommended policy progression

Start with monitoring policy and alignment settings

DMARC ties SPF and DKIM together and adds two things receivers care about: alignment with the visible From domain and an explicit policy for what to do when alignment fails.

Start with a monitoring-only record so you can see what is sending as your domain before you block anything:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r; pct=100

Key settings to decide up front:

p=none first: you get reports without risking legitimate mail being rejected.
adkim and aspf control alignment strictness. r (relaxed) is the most common starting point because it is more forgiving for subdomains and vendor setups.
pct=100 is fine even in monitoring mode. It does not enforce anything when p=none, but it keeps your record consistent as you move policies later.

Once reports look clean and all real senders pass alignment, progress in stages: p=quarantine (often with a lower pct) and then p=reject.

RUA and RUF reporting addresses

DMARC reports come in two flavors:

RUA (aggregate reports): the main one you want. They are periodic summaries showing which sources passed or failed.
RUF (forensic/failure reports): not consistently sent by receivers and can raise privacy concerns, so many teams skip it.

Use an inbox or alias you can manage long-term, not a personal mailbox. A shared address like dmarc-reports@ is common, or a mailbox routed into your monitoring workflow.

Handling subdomains with sp and organizational domains

If you send from subdomains, DMARC gives you control with the sp tag. For example, you can keep the parent domain cautious while enforcing more strictly on subdomains (or vice versa):

v=DMARC1; p=none; sp=quarantine; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r

Also keep in mind that DMARC is evaluated at the organizational domain level (the registered domain plus public suffix). That matters if you have multiple subdomains and want consistent enforcement and reporting across them.

How to validate SPF, DKIM, and DMARC after DNS changes

Verify DNS records and propagation

After you add SPF, DKIM, and DMARC, verify that the records exist in public DNS and match what you intended. Do not rely on what your DNS dashboard shows. Receivers only care about what they can query.

Check:

SPF: a TXT record on the root (or the exact subdomain you are sending from).
DKIM: a TXT or CNAME at selector._domainkey.yourdomain.com.
DMARC: a TXT record at _dmarc.yourdomain.com.

Propagation can take minutes or longer depending on DNS TTL and provider behavior. If a record is not showing up, the most common causes are publishing it under the wrong host name (for example, adding _dmarc.yourdomain.com.yourdomain.com) or having multiple competing TXT records.

Send a test email and confirm authentication results

Once DNS is visible, send a test email from your new sending domain through your real sending path (for example, Mailscribe). Send it to a mailbox you can inspect easily, like a Gmail or Outlook.com account.

What you are looking for is simple: SPF pass, DKIM pass, DMARC pass. If one fails, fix that first before moving your DMARC policy beyond monitoring.

Reading SPF, DKIM, and DMARC results in message headers

Open the message and view the full headers. Look for lines like:

Authentication-Results: (often contains SPF, DKIM, and DMARC outcomes)
Received-SPF: (SPF evaluation)
DKIM-Signature: (shows d= and s= values used for signing)

Common header patterns you want to see:

spf=pass for the domain used in the return-path or envelope sender
dkim=pass for the domain in d=
dmarc=pass for the visible From domain

If SPF and DKIM both pass but DMARC fails, that usually means an alignment mismatch, not a DNS typo.

Confirm alignment for the visible From domain

Alignment is the final check. DMARC does not care that “some SPF passed” or “some DKIM passed.” It cares that SPF and/or DKIM passed and aligned with the domain recipients see in the From address.

Confirm these match your plan:

The visible From domain is correct (no unexpected subdomain).
DKIM d= matches the From domain (or aligns under relaxed alignment).
SPF is evaluated on a domain that aligns with the From domain, which often depends on how your platform sets the return-path.

When in doubt, prioritize DKIM alignment. In many real-world setups, DKIM is the most reliable way to keep DMARC passing across forwards and complex routing.

Common SPF, DKIM, and DMARC setup errors and fixes

Common TXT host name and formatting mistakes

Most authentication problems come down to DNS details, not the concepts.

A few high-frequency mistakes:

Publishing to the wrong host name. DMARC must live at _dmarc.yourdomain.com. DKIM must live at selector._domainkey.yourdomain.com. Many DNS UIs auto-append the domain, so typing the full domain name can accidentally double it.
Multiple SPF records. SPF should be a single TXT record per domain. If you see two separate TXT records that both start with v=spf1, merge them.
Broken quoting or line breaks. Long TXT values (DKIM keys in particular) can be split across quoted strings, but the content must remain exact. Copy-paste changes, smart quotes, or missing semicolons can break evaluation.
Wrong record type. If your platform expects a CNAME for DKIM and you publish a TXT (or vice versa), DKIM will fail even though “a record exists.”

Fix approach: confirm the exact host and value required by the sending platform, then verify what is publicly resolvable. Small formatting differences matter.

DKIM failures from selector or key mismatches

DKIM failures usually mean the signature in the email cannot be validated against the key in DNS.

Common causes:

Wrong selector. Your platform signs with s=s1, but DNS only has s2._domainkey.... Fix by publishing the missing selector record or switching the platform to the selector you published.
Wrong domain in the DKIM record. The key is on selector._domainkey.news.yourdomain.com, but the signature uses d=yourdomain.com (or the reverse). Publish the record under the correct domain that matches d=.
Key was regenerated but DNS was not updated. If you click “regenerate DKIM” in a platform, the old DNS key becomes invalid. Update DNS to the new public key immediately.

Also watch for “pass sometimes, fail sometimes.” That often points to multiple outbound systems signing differently, or DNS split-brain where different resolvers are seeing different records.

DMARC failures from misalignment or missing reports

A DMARC fail with SPF pass and DKIM pass is a classic sign of misalignment.

Typical scenarios:

SPF passes for a vendor return-path domain, not your From domain. That can still be fine if DKIM aligns, but it will fail DMARC if DKIM is missing or misaligned.
DKIM passes with the wrong d= domain. For example, it passes with a vendor domain, but your From domain is different. Fix by enabling custom DKIM for your domain so d= aligns.
From domain differs from the domain you authenticated. This happens when teams send from brand.com but configure authentication on mail.brand.com without understanding alignment settings.

If you are not receiving DMARC reports, the most common fixes are simple: make sure the DMARC record includes a valid rua=mailto: address, that the mailbox exists, and that your DNS value uses proper semicolons and spacing. Aggregate reporting is what lets you move from p=none to enforcement without guessing.

Ongoing monitoring and tuning after DMARC enforcement

Using DMARC reports to find legitimate senders

DMARC reports are your map of what is really sending as your domain. They help you spot two things fast: unknown sources that should be blocked, and legitimate tools that need to be authenticated correctly.

In practice, use reports to build and maintain a “sender inventory.” For each source you see, confirm:

What system it is (Mailscribe, helpdesk, CRM, website forms, internal servers).
Whether it passes SPF and DKIM.
Whether it passes DMARC alignment with the visible From domain.

If you see a legitimate sender failing, fix that sender first (usually by adding an SPF include, enabling DKIM signing, or changing the From domain). Do not jump to stricter DMARC until your known sources are clean.

Moving from p=none to quarantine or reject safely

A safe policy progression is gradual. Once reports show consistent DMARC pass for your real senders, move to enforcement in steps:

p=quarantine with a smaller percentage (for example, pct=10 to start).
Increase pct over time as failures drop.
Move to p=reject when you are confident only unauthorized mail is failing.

Quarantine is a useful middle step because it pressures failures into spam rather than bouncing everything outright. Reject is stronger and usually the end goal for domains that are frequently spoofed.

Keeping third-party services aligned over time

The biggest long-term DMARC risk is change: new tools, new teams, and “quick” email features turned on without updating authentication.

To keep alignment stable:

Require that any new email tool can either sign DKIM with your domain or use a From domain you control (often a dedicated subdomain).
Recheck SPF lookup count when adding vendors, since “one more include” can push you over the limit.
Rotate DKIM selectors on a schedule, and remove old selectors only after you are sure they are unused.
Review DMARC reports regularly, especially after marketing launches, support platform migrations, or DNS changes.

If you treat authentication as a living configuration, not a one-time setup, your deliverability stays steady and DMARC enforcement keeps doing its job.