DMARC reports

Mailbox providers send a daily report about what they received with your domain. MailSolid reads them for you and shows who sends as you, what fails and when you can tighten your policy.

MailSolid · User guideReviewed for version 0.21.0

Who can do it: every member sees the reports. Adding or removing domains is for the owner and the admins; changing the report address of the workspace is for the owner only. The number of domains depends on your plan, and if your plan does not include DMARC reports the console says so.

Before you start: you need to be able to edit the DNS of the domain, because you will have to publish a record. MailSolid gives you the exact record but does not publish it for you.

What DMARC reports are

Providers such as Google and Microsoft send a report once a day about the mail they received with your domain: who sent it and whether it passed SPF, DKIM and DMARC. MailSolid receives them at an address of your workspace and shows them by domain. You only see the mail that reached those providers’ mailboxes.

Add a domain

1. Open DMARC in the sidebar.
2. Under Add a domain, choose My DNS (TXT) to manage the record at your provider, or MailSolid (CNAME) to host the policy and manage it in the console. If your plan, capacity or permissions do not allow hosting, the reason is shown.
3. Type the domain or pick one the workspace already knows (From this workspace:) and press Add domain.
4. TXT shows Publish this record for and the record to copy. CNAME opens the hosting assistant: review your current record, prepare the policy and follow the instructions to publish the CNAME at your DNS provider. Choosing CNAME does not automatically publish a policy or change your DNS.

The N of M domains counter shows how many the workspace uses out of what the plan allows. If it is full, remove one to add another.

Publish the record

Reports only arrive if the DMARC record of the domain says where to send them. That is what the rua tag does. MailSolid reads your public DNS and proposes:

• If the domain already has a DMARC record: the same record with our address in the rua. Your policy and the other tags do not change.
• If it has none: a new record that only watches (p=none): it does not change how your mail is delivered, and the reports start to arrive.

If the rua already has addresses of yours, you choose what to do:

• Add our address: your current addresses keep receiving reports too.
• Replace the current addresses: only ours stays. Before you decide, the console shows which addresses will stop receiving reports.

If the rua already has two or more addresses, keep in mind that some receivers only send reports to the first two: put ours among them (or remove one you no longer use).

Then:

1. Copy the record with the copy button (use the short name if your panel adds the domain by itself) and publish it at your DNS provider.
2. Press Check the record. MailSolid reads the public DNS and tells you whether it already points to us. If you just changed it, DNS can take a few minutes (sometimes an hour): check again.
3. When it says Verified, wait: providers send the reports once a day and the first one usually takes 24 to 48 hours.

In some cases MailSolid does not propose a record and explains why: a subdomain that inherits the record of the main domain (add our address there, or publish its own record for the subdomain), a record delegated to another service through a CNAME, more than one DMARC record (receivers ignore all of them) or an invalid record. If the DNS could not be read, nothing is wrong with your domain because of that: check again in a few minutes.

States of a domain

State	What it means
Waiting for the record	The record that sends us the reports has not been published yet.
Verified, waiting for reports	The record points to us and no report has arrived yet.
Receiving reports	Reports are arriving.
No reports for 3 days	They stopped arriving. Check that the record still sends the reports to us.
Paused by plan	Your plan does not cover this domain right now; new reports are discarded until you remove another domain.

Read the result of a domain

When you open a domain you see, from top to bottom:

1. The verdict and the current policy. It says, for example, All your legitimate mail passes DMARC, or which source fails and how many messages in the period. With 7 days, 30 days or 90 days you change the period. Only reports from trusted reporters count; if there are only reports from others, the verdict waits.
2. A daily chart of the messages that passed, failed and were forwarded.
3. Recent alerts for the domain (last 30 days).
4. The DMARC record, while no reports have arrived yet (or if they stopped).
5. Sources: who sent mail with your domain, grouped by organization.
6. Policy advisor.
7. DKIM and SPF.
8. Reporters and Received reports.

Sources

Each source has a status:

Status	What it means
Authorized	It passes DMARC.
Review	It is legitimate mail that fails, because neither DKIM nor SPF pass aligned with your domain. Set up DKIM for your domain in that service (or add it to your SPF) before you tighten the policy.
Unknown source	Someone sends as you and we do not recognize it: probably spoofing (or forwarding). A stricter policy stops it.

You can filter the table by All, Failing and Forwarded, and see the IPs of each source (with a copy button).

Forwarding. Forwarded mail (mailing lists, redirections) can fail DMARC without being a problem of yours. When the receiver says so, MailSolid counts it separately, as forwarded, and does not treat it as a failing source or use it in the alerts or the advice. How do we know? shows the limits: an aggregate report does not always say why your policy was not applied, so some forwarding may show up among the unknown sources.

Policy advisor

It looks at the reports from trusted reporters in the last 14 days and tells you what to do with your policy:

• You can move to p=quarantine / p=reject (or apply it to all your mail, by removing pct) when all your legitimate mail passes DMARC. It gives you the new value of the record to copy.
• Do not raise the policy yet if a legitimate source fails: it tells you which one and how many messages would be affected. Fix it first.
• We need a few more days of reports if there are not enough yet to advise you.
• Your policy is already at its strictest if you are already at p=reject for all your mail.

To publish the change, the Open the DMARC fix in Domain health button takes you to the card with the record.

DKIM and SPF

• DKIM lists the selectors that signed your mail in the last 30 days, their alignment, how many messages and the state of each key in the DNS (Good, Could be stronger, Weak, Missing, Revoked, Unreadable key). 2048 bits is recommended. Keys are read once a day; one that could not be read is not counted as broken.
• SPF compares who sends as your domain with what your SPF record authorizes: it shows the senders SPF does not cover and what to add (always exact IPs, never ranges), and each term of the record (Authorizes mail, Redundant, No mail: candidate to remove). It also warns when the record is close to or over the limit of 10 DNS lookups. MailSolid never changes your DNS.

Reporters and reports

Reporters lists the providers that sent reports. The Trusted ones (Google, Microsoft and others) are the only ones that count for the verdict, the policy and the alerts, so a fake report cannot change them. Received reports lists each report with its date and messages.

If a report was not saved, Discarded reports explains why (for example, the record no longer sends us the reports, the domain is not registered in this workspace, it arrived at an old address, the file could not be read or the sender could not prove it is who it claims to be). If the console warns about reports for domains that are not registered here, add them if they are yours.

The report address of the workspace

All the domains of the workspace share one address, shown at the bottom under Report address of this workspace, with a button to copy it. It is the one that goes in the rua of each record.

Only the owner can change it, and it is best to do so only if someone is sending you fake reports:

1. Press Change the address and type the workspace name to confirm.
2. The previous address keeps working for 7 days. In that time, change the rua of all your domains to the new one; after that, reports sent to the previous one are discarded.
3. If you change it again during those 7 days, the oldest address stops working right away and reports sent to it are discarded.

There is a maximum number of changes: when you reach it, the console says so and no longer offers to change it.

Remove a domain

On the domain, Remove domain deletes its reports, sources and history right away. Remove our address from its DMARC record too; otherwise the following reports are discarded. To remove the domain from monitoring and diagnoses too, use Remove from workspace on its page in Domains.

DMARC alerts

If there is a problem, MailSolid warns you in the console, by email and in your integrations. The types are: new source that fails, source that starts failing, possible spoofing, reports that stop arriving, DKIM signature that starts failing, weak DKIM key and SPF record with errors. Only reports from trusted reporters count. See Alerts and integrations.

If something fails

• “The record does not include our address yet”: either you have not published it yet, or the DNS has not updated. Wait a few minutes and check again.
• “No reports for 3 days”: check that the record still sends us the reports and has not been changed.
• Nothing arrives: providers send one report a day; the first takes 24 to 48 hours. You only get reports about what they received.
• “Your plan allows N domains in DMARC reports”: remove a domain to add another, or check your Plan.
• I see reports but the verdict says “No reports from trusted reporters yet”: the verdict, the advice and the alerts wait for reports from Google, Microsoft and other trusted reporters; meanwhile the chart and the sources show everything.

Related guides

• Domain health and Monitoring
• Alerts and integrations

Domain detail and transport (0.20)

Open a domain in Domains for its summary and latest change. You can watch it there and open DNS and diagnosis for the complete report, checks and tools. DMARC, MTA-STS and TLS tabs target that domain. Protection also has dedicated MTA-STS and TLS reception entries. Pending infrastructure remains explicit: preparing a policy does not publish DNS or certificates.

Set up TLS report reception

TLS-RPT reports encryption failures observed by sending providers. Do not send a test email to the displayed address: publish it in DNS.

1. Open the domain in TLS report reception. If reception is not enabled, wait for it to be enabled; do not invent an address.
2. In your DNS panel, create a TXT record using the exact Name and Value shown in Set up TLS reports. Some panels append the domain and only need _smtp._tls as the name.
3. If you already have TLSRPTv1, preserve the other destinations: add this address to its comma-separated rua list. Use a single policy record.
4. Save the change and select Verify DNS record. This only reads DNS; it does not change records or prove that reports have already arrived.
5. Wait for reports: providers typically take24 to48hours. If none arrive, delivery health is still unknown. A lookup error is not presented as a correct DNS record.

MTA-STS changes remain restricted to the workspace owner. Working in a workspace does not repeatedly request a second factor; sign-in factors and account security still apply.

Set up hosted MTA-STS

MTA-STS lets senders check encrypted delivery to your mail servers. MailSolid hosts the policy file; you publish the records at your domain’s DNS provider. It does not change your mail provider or MX records.

1. As the owner, open the domain in Hosted MTA-STS. You need hosted DMARC capacity in the plan and the domain report address verified in DNS. If hosting is not enabled, the console explains this and disables preparation.
2. Choose Prepare hosted MTA-STS. The MX servers and existing policy are checked. A new policy starts in testing; an existing policy is imported without lowering its protection. An existing enforce policy may need certificate prevalidation by the operator. Keep the current DNS for now.
3. When the table appears, copy its three CNAMEs to your DNS provider: mta-sts serves the HTTPS policy, _mta-sts announces its version and _smtp._tls directs TLS reports. Use the exact names and targets shown. Some DNS panels append the domain automatically. A CNAME cannot share its name with a TXT record: review the existing policy and TLS report destinations before replacing them.
4. Save the records and choose Check setup. This verifies CNAMEs, MX coverage, the HTTPS file and its certificate. Preparation alone does not mean hosting is verified. Allow DNS propagation if a record is missing.

The file is served at https://mta-sts.your-domain/.well-known/mta-sts.txt: MailSolid hosts it. Do not copy its contents into a TXT record or upload it to your website. View the hosted policy file lets you inspect it.

testing does not require senders to block deliveries because of this policy. enforce requires valid encrypted delivery to covered servers and may prevent delivery if they are misconfigured. Review coverage and reports before tightening a policy. Reports also need TLS-RPT to be configured.

If preparation fails, follow the specific reason: plan, DMARC ownership, MX, DNS or certificate. For an unknown result, choose Refresh status before retrying: it reads the saved state without preparing again. Keep the existing protection; a partial failure does not prove that nothing was published.