How to check your email authentication.
Start with a message sent through the service you actually use. CheckDMARC brings the receiving server’s authentication results, sending identities and current DNS records into one report. Choose a live email test, analyze a message you already have, or explore the sample first. No account is required.
Choose the right test
The three options answer different questions. Use a real message to investigate your own setup; the sample only demonstrates what the report looks like.
| Method | Use it when | What you need |
|---|---|---|
| Send test email | You can send from the mailbox, website, newsletter service or other sender you want to check. | Access to that sending account and a new temporary test address. |
| Paste headers | You already have a received message and want to understand its authentication results. | The complete original headers, including From and Authentication-Results or ARC-Authentication-Results. |
| Sample report | You want to learn how the report works before running your own check. | Nothing. The example uses fictional headers and fixed DNS records. |
Send a test email, step by step
This option shows how a message from your real sending route is reported by our receiving service. Testing your personal mailbox does not test a separate newsletter or invoicing platform: send a message from each service you want to assess.
Each address is intended for one test message and expires after 30 minutes. Use Start new test to check another account or sending service.
Create a fresh address
On the email check, select Send test email and then Create test address. While the address is being created, you will see Creating address… hold on…. Wait until the full address appears.
Copy the complete address
Use Copy address so every character is included. The address is temporary; its expiry time is shown beside it. Do not reuse an address from a completed or expired test.
Send through the account you are checking
Compose a simple new message to the test address. Use the same mailbox or sending service you use for real mail. A short, non-sensitive test message is enough; attachments are unnecessary.
Keep the test open
Waiting for email… means that the address is ready. Once a message arrives, the page switches to analysis and then displays the report. Refreshing the page does not restore the current test in the interface.
Read the result and repeat after changes
Check the DMARC verdict, the SPF and DKIM identities, alignment and the published records. After updating your provider or DNS, create a new address and send a new message through the same route.
Analyze a message you already have
Use Paste headers when the message has already reached a mailbox. Copy its original technical headers, rather than forwarding the message or copying the sender, subject and body from the normal reading view.
The paste option interprets the headers you supply. It does not receive that message again or independently re-verify its DKIM cryptographic signature. Edited or incomplete headers can produce an incomplete picture.
When present, header history shows Authentication-Results-Original, ARC-carried assertions, forwarding markers and selected Microsoft filtering fields alongside the selected receiver result. Earlier passes never replace that result and are not independently verified. This extra diagnosis applies to Paste headers and its shared reports; the live test reports what our receiving service saw.
Open the received copy
Choose the message in the recipient’s mailbox. A sent-folder copy may not contain the authentication results added by the receiving server.
Copy the original headers
Use your mail app’s original-message or message-details view. Preserve complete lines and their wrapped continuation lines. The message body and attachments are not needed.
Paste and analyze
Open the email check, select Paste headers, paste into Message headers or source, and choose Analyze message source. The app reads the authentication evidence and looks up current SPF and DMARC records.
Check for missing evidence
From identifies the visible sender. Authentication-Results, or the supported ARC alternative, supplies the reported checks. Return-Path and DKIM-Signature add useful context. If required headers are missing, return to the full original source.
Find the original headers in your mailbox
These instructions apply to the versions listed below. If a mobile app hides technical headers, use its web or desktop version. Headers can contain addresses, subjects and IP addresses, so review the source before pasting it.
If you copy the full raw source, the headers are the block before the first blank line. You can paste just that block. If your mailbox does not expose authentication headers, use a live email test instead.
| Mail app | Where to look |
|---|---|
| Gmail in a web browser | Beside Reply, open More, then Show original. Copy the header block from the original-message view. |
| New Outlook or Outlook on the web | Open More actions in the message, then View → View message details. Copy the headers shown there. |
| Classic Outlook for Windows | Open the message in its own window. Choose File → Properties and copy the Internet headers field. |
| iCloud Mail on the web | Open More on the message, then Show All Headers. Copy the technical headers rather than only the normal sender and subject display. |
Read your report in the right order
Begin with the DMARC verdict, then read the evidence underneath it. A green SPF or DKIM result is useful, but the domain that passed also matters. The report separates individual authentication checks from alignment and DNS observations. The DMARC detail indicates when a result was computed from the available checks rather than reported directly by the receiver.
| Report detail | What it tells you | What to check |
|---|---|---|
| DMARC verdict | The DMARC result from the available evidence, and the policy the report could identify. | A DMARC warning can mean a pass with p=none, or a policy that could not be confirmed. Read the explanation beside the verdict. |
| SPF and DKIM results | The checks reported by the receiving server and the domains involved. | SPF concerns the envelope sender; DKIM uses a signing domain. Neither domain is automatically the same as the visible From domain. |
| Identifier alignment | Whether a passing SPF or DKIM identity matches the visible sender closely enough for DMARC. | At least one authentication method must pass and align for DMARC. Both methods do not have to align for a DMARC pass. |
| Published records | The SPF and DMARC records found through DNS during analysis. | Check the domain shown above each record. DNS evidence may differ from the records in place when an older message was delivered. |
| SPF DNS lookups | The DNS lookup count and any problems found while examining the SPF record. | Investigate a limit warning or record error even if this particular receiver reported SPF as passing. |
| What to fix or improve | Suggested next steps based on the evidence available in this report. | Apply changes through the relevant mail provider, then send a fresh message to verify the same sending route again. |
Make sense of common results
A result is a description of one message and its evidence. These combinations are common when a provider sends on behalf of your domain or when the available headers are incomplete.
| What you see | What it can mean | Useful next step |
|---|---|---|
| SPF and DKIM pass, but DMARC fails | The authenticated domains may not align with the visible From domain. Strict alignment requirements can also matter. | Compare the identities shown in the report and your provider’s domain-authentication settings. |
| SPF is unaligned, DKIM is aligned, and DMARC passes | An aligned DKIM pass can satisfy DMARC even when the provider manages a different envelope sender domain. | Check the DKIM domain and the report’s explanation before treating the SPF alignment warning as a DMARC failure. |
| DMARC passes with a warning | The policy may be monitoring only, or the report may not have enough policy evidence. | Read the policy and DNS notes. Confirm legitimate sending services before changing an enforcement policy. |
| A check says not reported | The supplied headers do not include a usable result for that check. | Obtain complete original headers or use the live test. Missing evidence alone does not prove that a DNS record is absent. |
| A DNS record differs from the received result | The record may have changed since delivery, or a lookup may be incomplete. | Read the lookup note and repeat the test with a newly sent message after your DNS changes have propagated. |
Explore the sample without sending mail
The sample uses sender-example.test and fixed fictional DNS records. It shows passing SPF, DKIM and DMARC checks with aligned identities and a reject policy. Use it to learn where the report places domains, policies, published records and suggested next steps.
Opening or reloading the sample does not create a test address or send email. Its successful results describe the example, not your domain.
When a test does not finish
The status tells you which part of the process is still pending. Use a fresh test when an address has expired or you need to check a different message.
| Problem | What to try |
|---|---|
| Creating address… stays on screen | Wait for the request to finish. If the page reports an error, use Try again. Once an address appears, copy that new address before sending. |
| Waiting for email… continues | Verify the exact recipient address and that the message left your sending service. Check for a bounce, queue delay or outbound restriction. Keep this test tab open. |
| The session expired | Start a new test and send to its new address. An old test address cannot be reactivated by refreshing the page. |
| Paste analysis reports missing headers | Use the recipient’s full original source. Include From and Authentication-Results or ARC-Authentication-Results, preserving wrapped lines. |
| The report has a DNS lookup note | The email evidence may still be useful even when DNS is incomplete. Read the note, confirm your records with the provider and repeat the check when the lookup is available. |
Understand what this check can prove
CheckDMARC explains the authentication evidence for a message and adds current SPF and DMARC DNS information. It is a focused diagnostic check, not a guarantee that a message will reach the inbox or that its content is safe.
- A passing message does not test every mailbox, newsletter service or application that sends on behalf of your domain.
- The report does not measure spam reputation, engagement, blocklists or how every receiving provider will classify your message.
- Pasted Authentication-Results are interpreted as supplied; the paste option does not independently validate the original DKIM signature or an ARC chain.
- A DNS or provider change needs a new message and a new test to show the updated sending path.
Ready to check your own message?
Start with the sending service you use every day. Check one route, read the evidence, then repeat after a change.