Smart. Focused. Email.
Fast, cross-platform email designed to filter out the noise - so you can focus on what's important.
💡 DMARC record: A DNS entry that tells receiving mail servers what to do when an email claiming to be from your domain fails authentication checks. It builds on DKIM and SPF, and it's what actually enforces your email security policy. Think of it as the rule that decides whether a suspicious email gets delivered, quarantined, or rejected outright.
If you send email from a personal Gmail or Outlook address, you don't touch DMARC. Google and Microsoft handle it for you.
But if you send from a custom domain (you@yourcompany.com), this is your responsibility. Google and Yahoo announced in 2023 that bulk senders must have DMARC in place, and in late 2025 Gmail began strict enforcement, with non-compliant messages now facing temporary or permanent rejections. Microsoft followed with similar rules for high-volume senders in 2025.
You might bump into DMARC for the first time when your emails start landing in spam with no obvious reason. Or your domain registrar flags a missing authentication record. Or a client's IT team asks why your messages are failing their security checks. That's the moment this stops being abstract.
Sending newsletters or client emails from a custom domain? Set it up. It's not optional anymore.
Without a DMARC policy, a receiving server has to make its own judgment call when it gets an email that fails authentication checks. Sometimes it delivers anyway. Sometimes it doesn't. You have no visibility and no control.
DMARC changes that. Your record tells the receiving server exactly what to do with those failed emails: deliver normally (p=none), send to spam (p=quarantine), or reject entirely (p=reject). You also get reporting. Receiving servers send you daily data showing which messages passed authentication, which failed, and which IP addresses sent email on behalf of your domain.
That last part is where DMARC earns its keep for small businesses. Without it, someone could send phishing emails that look exactly like they came from your company address. Your customers get scammed, blame your brand, and you have no idea it's happening. The reporting tells you. The enforcement policy stops it.
It's not just a security measure. It's also an email deliverability one.
DMARC records live in your DNS as TXT records, published at _dmarc.yourdomain.com. A basic one looks like this:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
The key parts you need to understand:
p= is your policy. Start with none (monitoring only, no action taken). Once you've confirmed your legitimate emails are passing authentication, move to quarantine, then reject.
rua= is where your aggregate reports go. This is the email address that receives daily XML summaries from receiving servers. You'll want a dedicated inbox for these, since volume can add up quickly.
v=DMARC1 is just the version tag. Always DMARC1.
That's honestly most of what you need for a basic setup. The other tags (adkim=, aspf=, sp=) control alignment strictness and subdomain policy, but you don't need to worry about those on day one.
DMARC is a DNS operation. You're adding a text record to your domain. But before you touch anything, make sure SPF and DKIM are already configured and passing. Google recommends waiting 48 hours after setting up SPF and DKIM before adding your DMARC record. If you skip this step, you'll likely create delivery problems for your own email.
General setup (works for any domain registrar):
For Google Workspace: Google's official DMARC setup guide walks through the process specifically for Workspace domains.
For Microsoft 365: Microsoft's DMARC configuration documentation covers setup for 365 environments.
You don't need to configure anything inside Gmail, Outlook, or Spark. DMARC lives entirely at the DNS level, not inside your email client.
Set up SPF and DKIM first. DMARC won't work without them. If you skip this, you'll likely cause delivery problems for your own email before you fix anything. Don't skip it.
Start with p=none and wait. Don't rush to p=reject. Spend a week or two just collecting reports. You'll probably discover tools you forgot were sending on your behalf. That's normal. Common ones include Mailchimp, CRMs, invoicing software, anything that sends email using your domain address.
Check every tool that sends email for you. Each one needs to be properly authenticated before you tighten your policy. Missing one is the most common way this goes wrong. You flip to p=reject, and suddenly your Mailchimp newsletters stop delivering because you forgot to configure DKIM through your ESP.
Use a dashboard tool for reports. The raw reports are XML files. Unreadable for most people. Free tiers of EasyDMARC or MXToolbox turn them into something human. Use one.
Move to p=reject eventually. p=none is a starting point, not a destination. Until you get there, your domain is still spoofable. The goal is full enforcement. It just takes a few weeks to get there safely.