Sender authentication walkthrough
Set up SPF, DKIM, and DMARC for RouteKite.
Publish the DNS records shown for your sending domain, understand SPF, DKIM, DMARC, and the custom return path, and interpret RouteKite's manual authentication checks accurately.
Reviewed October 4, 2026
Copy the exact hosts, types, values, and MX priority for your domain.
Check DNS refreshes advisory observations with a checked time.
DNS presence and provider readiness do not determine where a recipient files an email.
Understand the four pieces
These controls relate to a message's sending identity. They do not replace recipient permission, useful content, sender reputation, or recipient filtering.
- SPF
- Sender Policy Framework lets a domain authorize sending hosts for the envelope identity. RouteKite shows the SPF TXT record for its custom MAIL FROM host, not a universal record to paste at every domain root.
- DKIM
- DomainKeys Identified Mail uses a message signature that a receiving system can verify using DNS-backed public-key information. Publish every DKIM CNAME that RouteKite displays; the selectors are domain-specific.
- DMARC
- Domain-based Message Authentication, Reporting, and Conformance relates authenticated SPF or DKIM identity to the visible From domain. At least one successful aligned mechanism is needed for a DMARC pass.
- Custom MAIL FROM
- The return-path domain supports envelope authentication and bounce routing. RouteKite requires its displayed MX and SPF records. This is separate from the visible Sending Address and your normal inbound mailbox MX records.
Protocol definitions: SPF, RFC 7208, DKIM, RFC 6376, and DMARC, RFC 9989. These describe the protocols, not a certification that every standard feature is implemented by RouteKite's DNS checker.
Publish the exact records for your domain
You need access to the DNS zone that actually serves the sending domain. Adding a record in an unused DNS account will not change the public result.
- Add the sending domain
Sign in to the intended workspace, open Domains, and add a domain you control. Open that domain's DNS Records section.
- Publish every required DKIM CNAME
Copy each Host / Name and Value exactly. Do not reuse another domain's selectors or replace the displayed record type with a TXT record.
- Publish the custom return-path records
Add the displayed MAIL FROM MX with its priority, and its SPF TXT at the displayed host. Do not replace the inbound MX records for your normal mailbox domain.
- Review DMARC separately
Publish or update the recommended DMARC TXT at the displayed _dmarc host. Preserve an intentional existing policy and reporting configuration; do not overwrite it blindly.
- Allow DNS to update, then check
Run Check DNS and review verification plus the Authentication findings in Overview. Add a Sending Address after the domain is verified, then use it in a reviewed campaign or API request.
DNS editors differ: some append the zone automatically, while others accept a full hostname. Confirm the final published name does not repeat your domain. Keep verification CNAMEs as DNS records rather than a proxied web destination.
At a given SPF host, keep one SPF policy instead of multiple competing v=spf1 records. If other authorized senders share that host, ask your DNS administrator to combine the policy correctly without deleting legitimate senders. This rule does not mean the root and a separate return-path subdomain must share one record.
Read Passed, Needs attention, and Could not check correctly
The findings are point-in-time observations. The displayed checked time tells you when RouteKite last looked, not that the record remains correct indefinitely.
- Passed
- The expected checked record is present under the implemented rules. DKIM and custom MAIL FROM also require the current delivery-provider verification result.
- Needs attention
- A record is missing, conflicts with the expected value, has an unsupported or invalid form, or is still waiting for verification. Follow the specific remediation beside that row.
- Could not check
- A DNS lookup was unavailable. It is not a successful check or proof that the record is wrong. Check the DNS host and retry later.
RouteKite checks expected DKIM CNAME targets, the custom MAIL FROM MX, its SPF include and terminal policy, and DMARC syntax and policy. Provider verification remains the sending-readiness source of truth.
The checker does not validate every SPF include recursively, exhaustively audit the DNS zone, inspect a recipient's delivered message headers, or collect DMARC reports. A green DMARC row is not evidence that a particular email passed alignment.
Do not confuse a published DMARC policy with protection being proven
RouteKite's recommended starter record uses p=none. That does not request quarantine or rejection for mail that fails DMARC, and does not create a reporting mailbox.
If you want aggregate reports, configure a reporting destination you control and can review. RouteKite does not provide a DMARC reporting dashboard. A published record without a reporting destination is not evidence that anyone is monitoring those reports.
Before strengthening a policy, inventory every legitimate sending service and review actual authentication and alignment results. A stricter policy can affect valid mail from an overlooked sender. Do not weaken a working policy simply to match an illustrative starter record.
For a separately approved delivery to a mailbox you control, inspect the receiving system's original headers and authentication results. A RouteKite design preview is not that evidence, and sending a preview email is a real delivery. This walkthrough does not send a message or change DNS for you.