Everything you need to get started with OnlyDMARC and understand the DMARC ecosystem.
Get from zero to monitoring in under 10 minutes. Here's the full setup process.
Sign up at onlydmarc.com/signup to get started. After signing up, add your first domain from the dashboard.
OnlyDMARC receives DMARC aggregate reports at a shared reporting address. It's also shown on your domain's page in the dashboard once you've added a domain:
Add or update your DMARC DNS TXT record on _dmarc.yourdomain.com. If you don't have a DMARC record yet, start with p=none to monitor without affecting mail flow.
After updating your DNS, verify the record is live using the check tool in your dashboard, or run a DNS lookup:
Once your reporting record is live and reporting is active on your account, mailbox providers send aggregate reports on a daily cycle — the first data usually appears within a day or two. Google and Microsoft are typically first, followed by Yahoo and the rest.
A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. It tells mailbox providers what to do with messages that fail authentication, and where to send reports.
| Tag | Required | Description |
|---|---|---|
v=DMARC1 |
Yes | Protocol version identifier. Always DMARC1. |
p= |
Yes | Policy: none, quarantine, or reject. |
rua= |
Recommended | Aggregate report destination (your OnlyDMARC address). |
pct= |
No | Percentage of messages subject to policy (default 100). |
adkim= |
No | DKIM alignment mode: r (relaxed, default) or s (strict). |
aspf= |
No | SPF alignment mode: r (relaxed, default) or s (strict). |
sp= |
No | Subdomain policy. Inherits from p= if omitted. |
The rua= tag tells mailbox providers where to send aggregate reports — the daily XML summaries of who is sending mail as your domain and how it authenticated. This is the address OnlyDMARC listens on, so getting it right is what makes your dashboard fill with data.
OnlyDMARC receives aggregate reports at a shared reporting address, shown on your domain's page in the dashboard. It is:
Put the address in the rua= tag as a mailto: URI. If you already have a DMARC record, append it to the existing rua= tag (comma-separated) — don't create a second _dmarc record and don't change your p= policy.
You can list multiple destinations by separating them with commas — useful if you want a second team or provider to receive the same reports.
The OnlyDMARC REST API gives programmatic access to all your DMARC data. It's available on Professional and Enterprise plans.
All API requests must include your API token in the Authorization header:
Webhooks let OnlyDMARC push events to your own systems in real time, instead of you polling the API. When something worth knowing about happens — a new sending source appears, a domain's pass rate drops, or a DNS change is detected — we send an HTTP POST with a JSON payload to a URL you control.
Every delivery is a JSON body with an event type, a timestamp, and an event-specific data object:
OnlyDMARC includes a Model Context Protocol (MCP) server, allowing AI assistants like Claude to query your DMARC data directly.
MCP is an open standard that lets AI tools connect to external services. With the OnlyDMARC MCP server, you can ask questions like "What unknown sources are sending from example.com?" or "Show me all DMARC failures in the last 7 days" directly in your AI assistant.
Notifications keep you informed without having to watch the dashboard. When OnlyDMARC detects something worth your attention — a new sending source, a drop in authentication pass rate, or a DNS change — it can reach you through the channels you choose.
You can deliver notifications to one or more destinations per domain:
Choose which channels are active and how often you hear from us under Settings → Notifications in your dashboard. Digest and summary emails include a one-click opt-out.
OnlyDMARC can post your DMARC alerts and digests straight into a Microsoft Teams channel as readable cards, each with a link back into the app. Delivery uses a Teams Workflows webhook — a URL you generate in Teams and paste into your notification settings. Setup is a one-time task of about three minutes. It is not an installed Teams app or bot: nothing to approve in your tenant, no admin consent, just an outbound message to a URL you control.
In Teams, open the Workflows app and start from the built-in template "Post to a channel when a webhook request is received". Pick the team and channel you want the cards to land in, then finish the template — Teams shows you a webhook URL. Copy it. (OnlyDMARC can't create this for you — the URL only exists once you've made the Workflow.)
Open Settings → Notifications and find the Microsoft Teams card. Paste the URL into the Webhook URL field, turn the channel on, and Save. Surrounding spaces, or a wrapping pair of quotes or angle brackets from the copy, are trimmed for you; the URL must be https://.
Under the same settings, opt into the event types you want in Teams and, for the daily digest and weekly summary, set the hour and day. Teams receives the same condensed digest as Discord — headline counts, a pass-rate band, the top recommendation, and a link through to the detail in the app (the full breakdown stays in the email).
Press Send test. Within a few seconds the card tells you whether your Workflow accepted the request, and a test card should appear in your Teams channel. The card then asks "Did the card appear in Teams?" — answer Yes to dismiss it, or No to open the troubleshooting steps below. That check-in matters: OnlyDMARC can tell you the endpoint accepted the request, but only you can confirm the card actually posted to the channel (see the next section for why).
A Teams Workflow answers a webhook request with 202 Accepted the moment it receives it — before it decides whether to post anything. So "accepted" means your Workflow received the request, not that a card reached the channel. A Workflow that has been edited, disabled, or given extra conditions can accept the request and then quietly drop it. This is the one silent failure worth knowing about, and it's usually quick to fix:
The DKIM Diagnostic Report is a read-only view that explains, in one place, how DKIM is behaving for a monitored domain: which selectors are signing mail, whether their keys are actually published in DNS, and where signatures are failing to align. It turns raw aggregate-report data into a ranked list of things worth fixing.
Open Insights → DKIM Diagnostic for any domain you monitor, then choose a reporting period. Several places in the app deep-link straight into it — for example the DNS Posture page's diagnose chip and the Sender Inventory's View DKIM details link.
The report combines two sources: the DKIM results reported in your DMARC aggregate data, and the most recent DNS snapshot we already hold for the domain. It does not perform live DNS lookups and it does not verify individual signatures — it reports the published key and the reported outcomes.
The report is laid out top-to-bottom in priority order:
| Severity | What it means |
|---|---|
Critical |
Actively hurting delivery or authentication right now — e.g. a selector signing production mail whose key is missing from DNS, or a revoked key still in use. Fix first. |
Warning |
A weakness worth scheduling — e.g. an under-strength (1024-bit) RSA key, or alignment gaps that don't yet break DMARC. |
Info |
Context worth noting — e.g. a selector still in testing mode (t=y). No action required, but good to be aware of. |
Once a week we email you a short, forward-safe overview of how your domains are doing — designed to read in under a minute and link you straight to the page behind any issue. It's built from your most recent scan (not a live lookup), and it's delivered by email, Discord, or both, per your notification settings.
Every chip and domain row is a link to the exact page for that concern (Insights, DNS, or Analysis); the link text names the action (Fix → / View →) — never colour alone. Change the summary day or turn it off any time under Settings → Notifications; opt-out is one click.
Read the full Weekly Summary guide — a plain-language explainer of everything the summary contains, what each chip and link means, and how the day and opt-out work.
A compact reference for the DMARC terms most often used in onboarding and support content.
| Term | Definition |
|---|---|
| DMARC | A DNS-published policy that ties SPF and DKIM to the visible From domain and adds reporting and enforcement instructions. Stands for Domain-based Message Authentication, Reporting and Conformance. |
| SPF | A DNS record listing the servers or IP addresses authorised to send email for a domain. Stands for Sender Policy Framework. |
| DKIM | A cryptographic signature attached to email headers, used to verify message integrity and sender authenticity. Stands for DomainKeys Identified Mail. |
| Alignment | The requirement that the SPF or DKIM authenticated domain matches the visible From domain. Alignment is what makes DMARC meaningful — without it, passing SPF or DKIM alone doesn't prevent spoofing. |
| RUA | Aggregate report destination. The email address where mailbox providers send daily XML DMARC aggregate reports. Set via the rua= tag in your DMARC record. |
| RUF | Failure-report destination for message-level forensic reports, where supported. These contain more detail but are sent by fewer providers due to privacy concerns. |
p=none |
Monitoring-only DMARC policy. Messages that fail authentication are not affected — they're delivered normally. Reports are still sent, giving you visibility without any risk to mail flow. The recommended starting point. |
p=quarantine |
Policy asking receivers to treat failures as suspicious, typically routing them to the spam/junk folder rather than the inbox. An intermediate step between monitoring and full enforcement. |
p=reject |
Policy asking receivers to block and discard messages that fail DMARC authentication outright. Full enforcement. Required by PCI DSS v4.0 and UK government policy. |
| BIMI | Brand Indicators for Message Identification. A standard allowing verified brand logos to appear next to email in supported inboxes (e.g. Gmail) when DMARC is enforced at p=quarantine or higher. |
| Relaxed alignment | The default alignment mode (adkim=r, aspf=r). Allows the authenticated domain to be a parent of the From domain (e.g. subdomain passes if the root domain matches). |
| Strict alignment | Strict alignment mode (adkim=s, aspf=s). The authenticated domain must exactly match the From domain. More secure, but can cause issues with subdomains. |
| pct= | The percentage of failing messages that the DMARC policy should be applied to. Useful for gradual rollout: start with pct=5 and increase as you gain confidence. Defaults to 100. |
| Disposition | The action taken on a message based on DMARC evaluation: none, quarantine, or reject. OnlyDMARC surfaces disposition in each source row. |
| HELO/EHLO | The hostname a mail server announces during the SMTP handshake. Used as one input in SPF evaluation and shown in DMARC reports as an additional signal for identifying sending infrastructure. |
| Envelope-from | The sender address used in the SMTP envelope (also called the Return-Path or bounce address). Used by SPF for authentication. Different from the visible From header. |
| Header-from | The visible From address shown to email recipients. This is the domain DMARC alignment is evaluated against. The most important domain from a spoofing perspective. |
| MCP | Model Context Protocol. An open standard for connecting AI assistants to external tools and services. OnlyDMARC's MCP server enables AI-assisted DMARC investigation. |
Example DMARC records for common scenarios.
DMARC defines three policy levels, each progressively stronger.
p=none
No action taken on failing messages. All mail delivered normally. Reports sent to your RUA address. Use this to understand your sending landscape before enforcing.
p=quarantine
Failing messages are treated as suspicious. Most receivers route them to spam/junk. A useful intermediate step while you're still resolving unknown senders.
p=reject
Failing messages are outright rejected and not delivered. The strongest protection against spoofing. Required by PCI DSS v4.0 and UK government policy.