Skip to main content
Version: v2.90.x

DMARC Management

The DMARC record determines what receiving servers do with email that is sent using your domain but fails SPF or DKIM alignment. Tightening the policy from none to quarantine and reject stops spoofed sending; however, before you take that step you need to know who sends email on behalf of your domain and whether your legitimate services pass DMARC. Otherwise you also block email from your own billing system or newsletter service.

This information is in the aggregate reports (rua) that receiving providers (Google, Microsoft, Yahoo and others) send to the report address in your DMARC record. The reports are in XML format and hard to read by hand. The Monitor → DMARC Management screen collects these reports on DeepFilter, parses them and shows every source that sends email on behalf of your domain on a single screen; it lets you tell spoofed sending apart from misconfigured legitimate services.

note

DMARC Management is available only to the global administrator and works for the internal domains defined on the system. Accounts with the domain administrator and viewer roles do not see this page in the menu.

How It Works​

Each internal domain has a report address in the form dmarc-rapor@<domain>. Report collection is enabled per domain on the Setup & Settings tab. Once it is enabled:

  1. You add this address to the rua= (and, if you wish, ruf=) tag of your DMARC record. Because the address is in the same domain, no additional DNS authorization record is needed.
  2. Receiving providers send reports to this address, usually once a day. The first reports arrive within 24–48 hours.
  3. Email arriving at this address is not delivered to any user; DeepFilter parses the report, stores it and shows it on the screen.

If the DKIM signature of the server that sent the report cannot be verified, the report is marked as Unverified reporter: the report may be forged. These reports appear in the lists, but policy transition readiness and the own-server alert are calculated only from the data of reporters whose signature is verified.

In the toolbar at the top of the page you select the Domain and the Period (7, 30, 90 or 180 days); the Enabled / Not enabled status of the report address also appears here. The screen consists of five tabs: Overview, Sending Services, Aggregate Reports, Forensic Reports and Setup & Settings.

Setup & Settings​

Initial setup is done on this tab. Report collection setup consists of four steps; a completed step is marked Enabled and a pending step Pending.

  1. Enable the report address — Press Enable. Report collection can be enabled only for active internal domains. Use Disable to turn it off; once it is disabled, reports sent to this address are not accepted, and reports already received are kept for the retention period.
  2. Add the report address to your DMARC record — The screen shows the Current record in DNS and the Suggested record side by side. At your DNS provider, replace the _dmarc TXT record with the suggested record. Your policy (p=) and the other tags stay the same; existing report addresses are kept and reports go to all addresses. Once reports arrive, the Policy transition readiness card recommends the policy change.
  3. Verify in DNS — After updating the record, press Check DNS. DNS propagation may take a few minutes. A "DNS lookup failed" warning does not mean the record is missing; try again in a few minutes.
  4. Wait for the first reports — When the first report arrives, the step is completed and the date of the last report is shown.

The Settings section:

  • Retention period — How long aggregate and forensic reports are kept (30, 60, 90, 180 or 365 days). Reports are deleted at the end of the period.
  • Request forensic reports (ruf) — When on, ruf= and fo=1 are added to the suggested record; the headers of every email that fails DMARC are reported.
  • Warn separately about my own servers — Email sent from DeepFilter IPs that fails DMARC is shown as a red alert on the Overview.
  • Additional DeepFilter server IPs — The outbound IPs of the other DeepFilter nodes in a high-availability setup. Email coming from these IPs is classified as "this system". This server's own IPs appear in the Detected automatically (read-only) list.
  • Weekly summary email — When on, a DMARC summary is sent to the administrator alert address every Monday at 09:00: for every domain with report collection enabled, the DMARC-passing/failing email of the last 7 days, new sending services, the own-server alert and the policy recommendation. The option creates a report definition of the DMARC weekly summary type on the Reports screen; the recipient, day and time are changed there (Edit in Reports). If no administrator alert address is set (see Notifications) or the limit of 20 report definitions is reached, the option cannot be turned on and the screen shows the reason.
tip

To build your entire DMARC record from scratch or to edit the policy, alignment and subdomain settings, you can use the DMARC Generator on the Health Tools screen. Simply enter the dmarc-rapor@<domain> address in the aggregate report address (rua) field.

Overview​

Summarizes the status for the selected domain and period on a single screen:

  • Record summary — DMARC policy (Enforced / Can be tightened), Report collection status (how many reports have arrived from how many organizations, the last report) and Unverified reports. The Open in Health Tools link opens all of the domain's DNS records on the Health Tools screen.
  • Indicators — The number of Total messages, DMARC pass, DMARC fail, SPF aligned, DKIM aligned and Sending services.
  • Message volume — A chart of daily DMARC-passing and failing email over the period.
  • Policy transition readiness — Shows the DMARC pass rate of legitimate traffic in a ring and recommends the next step for the policy (none → quarantine 25% → quarantine → reject). A pass rate of at least 90% is recommended for a staged transition (quarantine with pct=25) and at least 98% for a full transition. If there is no verified legitimate traffic in the selected period, the card shows No verified legitimate traffic in the selected period; a policy recommendation needs reports. instead of the rate and the recommendation. The quarantine suggestion on the Health Tools screen comes from the same decision as this card. The checklist below it lists what needs to be dealt with before the transition: the alignment of your own servers, services not yet reviewed, services marked as spoofed and the status of report collection.
  • Top sending services — The top services by volume; See all takes you to the Sending Services tab.

If your own servers fail DMARC​

If email sent on behalf of this domain from your DeepFilter servers does not achieve SPF and DKIM alignment, a red alert appears at the top of the Overview: "… messages sent from your own servers fail DMARC". If you move the policy to quarantine in this situation, your own email lands in quarantine at the recipient. The alert also shows the likely cause (for example, the envelope sender address not being aligned with the domain, or the DKIM key not matching the one in DNS) and offers the Go to DKIM settings and Health Tools › SPF shortcuts for the fix. The permanent solution is usually to enable DKIM signing for this domain and update the key in DNS (see Outbound Email, DKIM Signing section).

Sending Services​

Lists every source that sends email using your domain in the From address. Source IPs are grouped in the following order:

  1. The IPs of this DeepFilter system are shown in a single group named DeepFilter (this system).
  2. IPs marked individually as legitimate or spoofed do not join groups and stay on their own row.
  3. IPs with a verified reverse DNS record are grouped by their reverse DNS domain.
  4. IPs without reverse DNS are grouped by the network owner (ASN) that manages the IP block; the network owner's name is shown as the service name, with the ASN number in the form AS15169 · google.com below it and the reverse DNS domains, if any.
  5. IPs that fit none of these are listed one by one.

Naming by network owner also shows cloud and email services that have no reverse DNS record under a recognizable name.

Table columns: Sending service, Class, Volume, DMARC pass, SPF aligned, DKIM aligned and IPs. Clicking a row opens the service's Source IPs detail: for each IP, the From, reverse DNS, envelope sender, number of passing/failing messages and the reporting organizations.

Each service has a Class:

  • DeepFilter — this system — the IPs of this system (and of the other DeepFilter nodes added in the settings).
  • Legitimate (marked) / Spoofed (marked) — services you have marked.
  • Unidentified — services not yet reviewed.

From the Service actions menu on the row:

  • Mark as legitimate / Mark as spoofed / Remove label — classifies the service. Reviewing unidentified services is one of the steps of policy transition readiness.
  • Add to SPF — opens the Domain tab of the Health Tools screen with the domain preselected; you can add the service to the SPF record with the SPF Generator.
  • Copy IP list — copies the service's source IPs to the clipboard.
caution

Before marking a service as Spoofed, make sure it really is a source you do not recognize. A service you do not recognize may be a legitimate newsletter or notification service used by another unit of your organization.

Aggregate Reports​

Lists the aggregate reports (rua) received: Reporting organization, Report ID, Period, Records, Messages, Received and Status. A report received twice is counted once. The original of each report can be downloaded with Download XML.

The Status column takes three values:

  • Processed — the report was parsed and its data is reflected on the screen.
  • Duplicate — skipped — the same report was received before.
  • Rejected — the report was not processed; the reason is shown next to it (for example invalid XML, a report for another domain, an unsupported attachment type, or the size or daily report limit being exceeded).

Forensic Reports​

Forensic reports (ruf) contain the headers of individual emails that fail DMARC. Most large providers (e.g. Google, Microsoft) do not send forensic reports; you usually see fewer entries in this list. To receive forensic reports, turn on the Request forensic reports (ruf) option on the Setup & Settings tab and apply the suggested record to DNS.

The list shows the Date, Reporter, Source IP, Sender (From), Subject, Failed (SPF, DKIM, DMARC and so on) and Applied (what the recipient did with the email) columns. Clicking a row opens the email's headers, envelope sender and recipient information. If the email appears to come from your domain but was not sent from your servers, a Possible phishing warning appears.

DMARC Reports in Email Traffic​

Email arriving at the report address does not appear in the default list of the Email Traffic screen. To see it, select the DMARC report option in the Action filter; this option is visible only in the inbound direction and only to the global administrator.

Tightening the Policy — Recommended Flow​

  1. Enable report collection and accumulate at least a few weeks of reports.
  2. If there is an alert about your own servers on the Overview, resolve it first.
  3. On Sending Services, review every unidentified service: add the legitimate ones to your SPF record, configure DKIM signing for them and mark them as Legitimate; mark the ones you do not recognize as Spoofed.
  4. Following the Policy transition readiness recommendation, tighten the policy gradually: quarantine with pct=25 first, quarantine if the reports stay clean, and reject last.
Last updated on