DMARC

By pointing your domains' DMARC reporting at a dedicated mailbox and setting up DMARC integration, you can ingest aggregate DMARC reports into ThreatDefence for centralized monitoring of who is sending mail as your domains.

This setup enhances visibility into:

• Legitimate senders using your domains, including shadow IT and third-party services

• Spoofing and impersonation attempts against your brand

• SPF and DKIM alignment failures across your sending infrastructure

It enables more effective detection of brand impersonation and business email compromise, and provides the evidence needed to safely tighten your DMARC policy later.

The first reports typically arrive 24–48 hours after the DNS changes are published. You will need mail admin and DNS access to complete this process.

---

Before you begin:

• This mailbox must support IMAP over TLS on port 993 with a publicly valid certificate. STARTTLS on port 143 is not supported.

• Authentication is by username and password. OAuth is not supported, so you will likely need to generate an app password.

• We read the Inbox only. Do not add a rule or filter that files reports into a subfolder.

• This setup collects one dataset from your mailbox:

  • DMARC Aggregate Reports — the XML reports that receiving mail providers send to the address published in your DMARC record.

---

Step 1: Create a dedicated mailbox

1. Create a real mailbox

   • It must be a mailbox that stores mail — not a distribution group or a forwarding alias.

   • For example, [e-mail].

2. Keep it dedicated to DMARC reports

   • Everything that lands in the Inbox gets processed, so this mailbox should not be used for anything else.

---

Step 2: Enable IMAP and issue a password

1. Enable IMAP access on the mailbox

   • Google Workspace — enable IMAP in Gmail settings, turn on 2-Step Verification, then generate an App Password. The host is imap.gmail.com.

   • Microsoft 365 — the host is outlook.office365.com.

   • Self-hosted — confirm IMAPS is available on port 993 with a publicly valid certificate.

2. Record the credentials

   • You will need the IMAP hostname, the mailbox address (used as the username) and the app password.

Important: If you are on Microsoft 365, check this before going any further. Most tenants block basic authentication for IMAP by default. Confirm it can be permitted for this mailbox — if your policy forbids it, tell us now and we will arrange a different collection method.

---

Step 3: Publish the DMARC record

1. Create one TXT record per domain you want monitored

   • Type: TXT

   • Host: _dmarc

   • TTL: 3600

   • Value:

v=DMARC1; p=none; rua=mailto:[e-mail]

1. Include every domain you own

   • Add parked domains and domains you never send from — those are the most attractive to spoof.

Note: Keep the policy set to p=none. It is monitor-only and changes nothing about mail delivery. Tightening to quarantine or reject comes later, once reports show which of your legitimate senders would be affected.

---

Step 5: Verify the record

1. Query the record

   • On macOS or Linux, run dig +short TXT _dmarc.yourdomain.com.

   • On Windows, run nslookup -type=TXT _dmarc.yourdomain.com.

2. Confirm the result

   • You should see your v=DMARC1 string returned.

---

Onboarding the integration

Please follow the Managing Integrations instructions and onboard the integration. The above saved credentailas are required in this process.

---

If encountered difficulties with onboarding, please email the following credentials to [e-mail]

• IMAP hostname

• Mailbox address — used as the username

• App password — please send this via a secure channel, not plain email

• List of monitored domains

Note: We read mail from this mailbox but never delete it, so apply your own retention policy to it. Password rotation, MFA changes or a mailbox migration will break collection silently, so please let us know in advance of any of these.