DMARC is a DNS record that tells receiving mail servers what to do with email that claims to come from your domain but fails authentication. You set it up safely by checking your SPF and DKIM first, publishing a monitoring only record with the policy p=none, reading the reports, fixing legitimate senders that fail, and only then moving to quarantine and reject.<\/p>\n\n\n\n
A p=none record never blocks mail, so starting there cannot break your email.<\/p>\n\n\n\n
This guide walks through each step in order, with example records you can adapt. DMARC does not replace SPF or DKIM. It builds on both, so they must work first.<\/p>\n\n\n\n
We have hosted more than 700,000 websites over 20+ years, and email authentication tickets follow a pattern. Most trouble comes from a forgotten sender, such as an invoicing tool or a contact form, that nobody listed before tightening the policy.<\/p>\n\n\n\n
DMARC, short for Domain based Message Authentication, Reporting and Conformance, lets you publish what receivers should do when a message fails SPF and DKIM checks tied to your domain. Your business needs it to stop others from impersonating you, to improve trust with mailbox providers, and to see who is sending mail in your name.<\/p>\n\n\n\n
DMARC adds a rule on top of SPF and DKIM. It asks receivers to check that a message passed at least one of them and that the passing domain matches the address in the From line. Then it tells them what to do if it did not.<\/p>\n\n\n\n
It also sends you reports. Receivers such as Gmail and Outlook.com can mail you daily summaries of which servers sent mail using your domain, and whether those messages passed.<\/p>\n\n\n\n
Those reports are the main reason to start early. They show you every sender, including ones you forgot, and any unknown ones trying to impersonate you.<\/p>\n\n\n\n
DMARC does not encrypt email or stop spam sent to you. It protects the use of your domain name in the From address.<\/p>\n\n\n\n
Email was designed without sender verification. Anyone can write any address in the From line, which is how spoofing works. An attacker can send a message that appears to come from your domain.<\/p>\n\n\n\n
Common uses are fake invoices, payment change requests, and phishing messages sent to your customers or staff. The victims trust the name they see and never check the technical details.<\/p>\n\n\n\n
The damage lands on you. Customers lose money, your reputation suffers, and your real emails may start landing in spam.<\/p>\n\n\n\n
DMARC cannot stop every impersonation attempt, such as look alike domains with slightly different spelling. It does close the door on exact copies of your own domain.<\/p>\n\n\n\n
SPF is a DNS list of servers allowed to send mail for your domain. DKIM adds a cryptographic signature to each message, which the receiver checks against a public key in your DNS. DMARC ties them together and sets the policy.<\/p>\n\n\n\n
A message passes DMARC when SPF or DKIM passes and the passing domain aligns with the visible From domain. You need only one to pass and align, but having both is safer.<\/p>\n\n\n\n
Forwarding is a good example. SPF often breaks when a message is forwarded, because the forwarding server is not on your list. DKIM usually survives, which is why DKIM matters so much.<\/p>\n\n\n\n
Set up SPF and DKIM first. A DMARC record on top of broken SPF and DKIM only exposes the problems.<\/p>\n\n\n\n
Mailbox providers like senders who authenticate. Gmail and Yahoo have required SPF, DKIM, and a DMARC record from bulk senders since February 2024, and Microsoft began enforcing similar rules for Outlook.com on May 5, 2025<\/a>. The bulk threshold is about 5,000 messages a day, so many small businesses fall below it.<\/p>\n\n\n\n Even below that line, authentication helps. It reduces the chance that your real messages are treated as suspicious.<\/p>\n\n\n\n DMARC is also now a formal standard. The IETF published it as RFC 9989 in May 2026<\/a>, replacing the older specification. Major providers have been slower to update their own documentation.<\/p>\n\n\n\n Think of DMARC as a good habit, not a magic switch. It supports deliverability but does not guarantee inbox placement.<\/p>\n\n\n\n Before you publish anything, list every system that sends email as your domain. People usually remember the main mailbox provider and forget the rest.<\/p>\n\n\n\n Typical senders are your business email host, a newsletter tool, your website’s contact forms, an online store, a billing system, a CRM, and support software. If you resell hosting, billing software such as WHMCS also sends invoices and reminders.<\/p>\n\n\n\n If you run your own mail server on a USA VPS<\/a>, you also take on SPF, DKIM, and sending reputation yourself. Ask each team member what tools send mail for them. Check old invoices and tool subscriptions for forgotten services.<\/p>\n\n\n\n This list is the foundation of everything that follows. Anything missing from it is likely to fail DMARC later.<\/p>\n\n\n\n Check your SPF record, DKIM status for each sender, the platforms that send business and transactional mail, any website forms and CRM tools, and your existing DNS records for duplicates. Fix problems first, because DMARC reports will only repeat them.<\/p>\n\n\n\n SPF is a TXT record on your main domain that begins with v=spf1. Look it up with a free DNS tool and read what it authorizes.<\/p>\n\n\n\n v=spf1 include:_spf.example.net ~all<\/p>\n\n\n\n A domain must have only one SPF record. Two records cause SPF to fail, so merge them into one. This is a common mistake when a second service says to add its own record.<\/p>\n\n\n\n Check that each sender on your list appears in the record. Remove entries for services you no longer use.<\/p>\n\n\n\n The ending matters too. The tilde all means soft fail, and a dash all means hard fail. Do not change it until you have finished the rest of this guide.<\/p>\n\n\n\n DKIM needs a public key published in DNS, usually as a TXT or CNAME record under a name that includes a selector. Each sending service has its own selector and instructions.<\/p>\n\n\n\n In cPanel, the Email Deliverability tool shows whether SPF and DKIM are set up for each domain on the account. Check what your own panel provides.<\/p>\n\n\n\n For outside services such as newsletter tools, find their domain authentication settings and follow their steps. Many give you records to add to your DNS.<\/p>\n\n\n\n Send a test message to a mailbox you control. Then view the message source and look for dkim=pass in the authentication results.<\/p>\n\n\n\n Business mail is the messages people write. Transactional mail is automatic, such as order confirmations, password resets, and invoices. Both use your domain, and both must authenticate.<\/p>\n\n\n\n Transactional mail is where surprises hide. A website plugin may send through your web server instead of your mail provider, and that path may lack DKIM.<\/p>\n\n\n\n Write down for each sender what it sends, from which address, and how it authenticates. A simple table is enough.<\/p>\n\n\n\n For reliable outgoing delivery, look for a provider built to keep mail out of spam, and confirm how it works with your own domain settings.<\/p>\n\n\n\n Contact forms are a classic problem. Many send mail with your domain in the From line, directly from the web server. That server needs to be covered by SPF, or the form should send through an authenticated service.<\/p>\n\n\n\n Do the same check for CRMs, support desks, booking tools, and marketing platforms. Each one may need its own SPF include and DKIM record.<\/p>\n\n\n\n Some tools let you use their domain in the From line instead. That avoids the problem but looks less professional.<\/p>\n\n\n\n If you install WordPress with the Softaculous auto installer<\/a>, add an SMTP plugin that sends through your real mail account. It usually authenticates better than the default mail function.<\/p>\n\n\n\n Open your DNS zone and look for existing records at the DMARC name, which is _dmarc. If one already exists, edit it. Do not add a second.<\/p>\n\n\n\n Look for duplicate SPF records and old DKIM keys. Clean up what you no longer use, but do not delete anything you are unsure about.<\/p>\n\n\n\n If your DNS is managed outside your host, such as in CloudFlare CDN<\/a>, make sure you are editing the zone that is actually live. Check your nameservers first.<\/p>\n\n\n\n Make a copy of the current records before any change. It makes rollback easy. If you manage domains for clients, for example through a free domain reseller<\/a> account, repeat this check for each domain.<\/p>\n\n\n\n Publish a TXT record at _dmarc.yourdomain with the policy p=none and a reporting address, then verify it with a DNS lookup. A monitoring record does not block anything, so it cannot interrupt your mail. You then use the reports to decide what to fix.<\/p>\n\n\n\n A DMARC record is a TXT record made of tags separated by semicolons. The version tag v=DMARC1 comes first, and the policy tag p comes next. Those two are required.<\/p>\n\n\n\n The rua tag says where to send aggregate reports. It is not strictly required, but without it you learn nothing, so include it.<\/p>\n\n\n\n Other tags tune the behavior, such as sp for subdomains and adkim and aspf for alignment strictness. You can skip them at first, since the defaults are fine.<\/p>\n\n\n\n Older guides mention a pct tag for applying a policy to a percentage of mail. The 2026 standard removed it, so do not rely on it.<\/p>\n\n\n\n Start with p=none. It tells receivers to take no action on failing mail, and only to report. Nothing is blocked, quarantined, or rejected.<\/p>\n\n\n\n v=DMARC1; p=none; rua=mailto:dmarc@example.com<\/p>\n\n\n\n This is the safest first step. It gives you visibility without risk, which is the point.<\/p>\n\n\n\n Keep it in place while you collect reports. Many businesses stay on p=none for several weeks.<\/p>\n\n\n\n Use a mailbox or alias you control for the reporting address, and check that it can receive large attachments. Avoid adding other tags for now, because simple records are easier to check and harder to get wrong.<\/p>\n\n\n\n A p=none record also meets the minimum that Gmail and Yahoo ask of bulk senders.<\/p>\n\n\n\n The record goes at the name _dmarc under your domain. In many DNS panels, you enter only _dmarc as the host, and the panel adds your domain automatically. Entering the full name can create a doubled name that does not work.<\/p>\n\n\n\n The type is TXT. The value is the text of the record. Paste it exactly, with straight quotes if your panel asks for them.<\/p>\n\n\n\n Use your real address in the rua tag. A mailbox that nobody reads is a wasted opportunity.<\/p>\n\n\n\n If your host provides a DNS zone editor, check the record there after saving. Our shared web hosting<\/a> runs on cPanel, where the Zone Editor is the usual place, though you should check your own plan.<\/p>\n\n\n\n The rua tag takes a mailto address. Reports arrive as compressed XML attachments, often daily, from each receiver that checks your mail.<\/p>\n\n\n\n Use a dedicated mailbox, because reports can add up. A free or paid report analyzer can collect them and show them in a readable form.<\/p>\n\n\n\n If you send reports to an address at a different domain, that domain must publish a small record that authorizes it. Without it, receivers may not send the reports.<\/p>\n\n\n\n There is also a ruf tag for failure reports, but many receivers do not send them, and they can contain private message details. You can skip it.<\/p>\n\n\n\n Save the record, then check it with a DMARC lookup tool. It should show your policy and your reporting address with no errors.<\/p>\n\n\n\n DNS changes can take time to appear. Often it is minutes, but it can take longer, depending on cache settings.<\/p>\n\n\n\n Send a test message to a Gmail address and view the original message. The Authentication-Results line should show dmarc=pass if SPF or DKIM passes and aligns.<\/p>\n\n\n\n Verify before you do anything else. Do not increase enforcement until your lookup and test results are correct.<\/p>\n\n\n\n The policy is your instruction to receivers. None means monitor only, quarantine means treat failing mail as suspicious, usually by sending it to spam, and reject means refuse it. You move up these levels as you gain confidence.<\/p>\n\n\n\n With p=none, receivers evaluate DMARC and report the results, but they do not change how they handle the mail. A failing message is delivered or filtered as it would have been anyway.<\/p>\n\n\n\n Be clear on one point. p=none does not protect you from spoofing yet. It only shows you what is happening.<\/p>\n\n\n\n That is why you should not stay on it forever. Once you understand your senders, you should tighten the policy.<\/p>\n\n\n\n Keep in mind that mailbox providers still apply their own spam filtering. You may see effects on delivery from other causes even while DMARC itself is in monitoring mode.<\/p>\n\n\n\n Treat p=none as a survey, not a shield.<\/p>\n\n\n\n Move to quarantine when your reports show that every legitimate sender passes and aligns, and the remaining failures are unknown or suspicious sources. You should be able to explain every sender in the reports.<\/p>\n\n\n\n There is no fixed time. For a small business with few senders, a few weeks of clean reports may be enough. A business with many tools may need longer.<\/p>\n\n\n\n Change the record to p=quarantine and watch your mail and reports closely for the next few days. Be ready to go back to p=none if something breaks.<\/p>\n\n\n\n Tell your team before you change the policy, so they can report missing mail quickly.<\/p>\n\n\n\n With p=reject, receivers refuse mail that fails DMARC. The message does not reach the recipient, not even in spam. This gives the strongest protection against impersonation.<\/p>\n\n\n\n It also carries the highest risk. If a legitimate sender is missing from your setup, its mail is rejected, and the sender may get little warning.<\/p>\n\n\n\n Move to reject only after quarantine has run cleanly for a good period. Keep checking reports afterward, as new tools appear over time.<\/p>\n\n\n\n Many small businesses stop at quarantine, and that can be a reasonable choice. Reject is a goal, not a requirement.<\/p>\n\n\n\n Alignment means the domain that passed SPF or DKIM matches the domain in the visible From address. Without alignment, a pass does not count for DMARC.<\/p>\n\n\n\n There are two modes. Relaxed alignment allows subdomains to match, so mail.example.com aligns with example.com. Strict alignment requires an exact match. Relaxed is the default and works for most businesses.<\/p>\n\n\n\n A common failure is a service that passes SPF for its own domain, not yours. The message passes SPF but fails DMARC, because the domains do not align.<\/p>\n\n\n\n The fix is usually to set up domain authentication at that service, so it signs mail with your domain.<\/p>\n\n\n\n The right level depends on your setup. A business with one mail provider and a few tools can usually reach reject safely. One with many third party platforms may stay at quarantine longer.<\/p>\n\n\n\n Domains that never send email deserve the strictest policy, since any mail from them is fake. A simple record with p=reject and no senders protects them.<\/p>\n\n\n\n Think about the cost of a mistake. If missing one email costs you a major client, move slowly.<\/p>\n\n\n\n Review the choice as your tools change. There is no shame in a cautious policy that you maintain well.<\/p>\n\n\n\n Collect aggregate reports, read them with an analyzer, find legitimate senders that fail SPF or DKIM alignment, fix each one at its source, investigate unknown senders, and confirm results with message headers. Repeat until legitimate mail passes consistently.<\/p>\n\n\n\n An aggregate report is an XML file listing source IP addresses, how many messages each sent, and whether they passed SPF, DKIM, and DMARC. Each receiver sends its own, usually once a day.<\/p>\n\n\n\n The raw XML is hard to read. Use an analyzer to turn it into tables and charts.<\/p>\n\n\n\n Focus on three things: which sources send mail, how many messages, and whether they pass. Sources you recognize should pass. Sources you do not recognize need a closer look.<\/p>\n\n\n\n Reports cover only receivers that send them, so they do not show every message. Read them as a sample, not a complete record.<\/p>\n\n\n\n Match each failing source in your reports against your sender list. A source that belongs to a known service and fails is a configuration problem you can fix.<\/p>\n\n\n\n Check whether the failure is SPF, DKIM, or both, and whether it is an alignment failure. Each has a different fix.<\/p>\n\n\n\n Start with the highest volume sources. Fixing one large sender removes most of the noise.<\/p>\n\n\n\n Do not ignore small senders. A tool that sends only a handful of messages a month, such as a payroll system, can still matter a great deal.<\/p>\n\n\n\n Keep a log of each fix with the date, so you can see the failure count fall.<\/p>\n\n\n\n Most platforms offer domain authentication. You add DNS records they provide, and then they sign mail with your domain. After that, DKIM passes and aligns.<\/p>\n\n\n\n Be careful with SPF. Add the service’s include to your single SPF record, rather than creating a second one. Watch the lookup limit, which we cover below.<\/p>\n\n\n\n If you use billing software such as WHMCS<\/a>, check which mail path it uses for invoices and reminders, and authenticate that path. Our reseller plans include a free WHMCS license, so confirm current plan details.<\/p>\n\n\n\n After each change, send a test and look at the headers again.<\/p>\n\n\n\n A source you cannot match to any tool deserves investigation. Look up the address to see who owns it, and ask your team whether they know it.<\/p>\n\n\n\n It may be a forgotten tool, a former employee’s system, or an attacker. Do not panic, because a few unexplained sources are common.<\/p>\n\n\n\n If the source is malicious, a stricter policy will stop it. That is the point of moving beyond p=none.<\/p>\n\n\n\n If many suspicious sources appear, tighten your policy sooner and consider telling your customers to watch for fake messages.<\/p>\n\n\n\n The message header shows what receivers saw. In Gmail, open a message, choose show original, and read the SPF, DKIM, and DMARC results at the top.<\/p>\n\n\n\n Look for pass on all three, and check the domains listed. A pass for the wrong domain still fails alignment.<\/p>\n\n\n\n Testing tools can also send you a report on a test message. They are handy, but treat them as a second opinion.<\/p>\n\n\n\n Keep a few saved examples of good headers. Comparing a new test with a known good one makes problems easier to spot.<\/p>\n\n\n\n Test from every sender, not only your main mailbox. Each path can behave differently.<\/p>\n\n\n\n Raise enforcement in small steps, review every new email service before it sends as your domain, keep SPF within its lookup limit, watch subdomains and separate systems, and document every DNS change. DMARC needs upkeep, because your email tools change over time.<\/p>\n\n\n\n Plan the steps. As an illustration, you might run p=none for four weeks, fix failures, move to quarantine for four more weeks, then consider reject. Your own timing should follow your reports.<\/p>\n\n\n\n Do not rush because a guide says so. Move only when the data supports it.<\/p>\n\n\n\n Older guides use the pct tag to ease into enforcement. It was removed from the standard in 2026, although some receivers may still honor it<\/a>. Do not count on it, and step policies up directly.<\/p>\n\n\n\n Write the schedule down, and note who approves each change.<\/p>\n\n\n\n Every new tool that sends as your domain is a new risk. Before you sign up, ask whether it supports DKIM with your domain, and what it needs in your SPF record.<\/p>\n\n\n\n Set it up and test before you send real mail. A new newsletter tool that fails DMARC can damage your reputation on its first campaign.<\/p>\n\n\n\n Add each new service to your sender list the day you start using it.<\/p>\n\n\n\n Make this part of your normal process, such as a checklist for any new software that sends mail.<\/p>\n\n\n\n SPF allows only 10 DNS lookups per check. Each include, a, mx, and similar entry counts, along with lookups inside those includes. Go over the limit and SPF fails with an error.<\/p>\n\n\n\n Many businesses hit this limit after adding several services. Remove services you no longer use, and consider whether every include is needed.<\/p>\n\n\n\n Be careful with tools that flatten SPF records. Flattening swaps lookups for fixed addresses, which can go stale when a service changes its servers.<\/p>\n\n\n\n Check your SPF with a validator after every change.<\/p>\n\n\n\n Subdomains need attention. By default, your policy applies to them, but you can set a different one with the sp tag. The 2026 standard also adds an np tag for subdomains that do not exist, which helps block fake subdomain spoofing.<\/p>\n\n\n\n Some businesses send from separate subdomains, such as one for marketing and one for billing. Each should be authenticated, and each appears in reports.<\/p>\n\n\n\n Branch offices, acquired businesses, and old systems can have separate email setups. Include them in your review.<\/p>\n\n\n\n If you manage many client domains as a reseller<\/a>, keep a simple per domain checklist. If you also run resellers of your own, such as under a master reseller<\/a> arrangement, agree who owns each domain’s DNS.<\/p>\n\n\n\n Keep a log of every DNS change with the date, the old value, the new value, and the reason. It makes troubleshooting much easier.<\/p>\n\n\n\n Review reports on a schedule. Monthly is a sensible rhythm for a small business, and weekly during changes.<\/p>\n\n\n\n If you are unsure about a change, contact your host. Our end user support<\/a> page explains how support works for reseller customers, and we run 24\/7 support.<\/p>\n\n\n\nIdentifying the Email Services That Send Messages Using Your Domain<\/h3>\n\n\n\n
What Should You Check Before Setting Up a DMARC DNS Record?<\/h2>\n\n\n\n
Reviewing Your Existing SPF Record and Authorized Sending Sources<\/h3>\n\n\n\n
Checking Whether DKIM Is Enabled for Your Email Services<\/h3>\n\n\n\n
Listing Email Platforms Used for Business and Transactional Messages<\/h3>\n\n\n\n
Identifying Website Forms, CRM Systems and Third-Party Email Services<\/h3>\n\n\n\n
Checking Existing DNS Records to Avoid Duplicate or Conflicting Configurations<\/h3>\n\n\n\n
How Do You Create and Publish a DMARC Record Without Breaking Email?<\/h2>\n\n\n\n
Understanding the DMARC TXT Record Structure and Required Tags<\/h3>\n\n\n\n
Creating an Initial Monitoring Policy With p=none<\/h3>\n\n\n\n
Configuring the Correct DMARC Hostname and DNS Record Value<\/h3>\n\n\n\n
Adding an Aggregate Reporting Address With the RUA Tag<\/h3>\n\n\n\n
Publishing the Record and Verifying It Through DNS Lookup Tools<\/h3>\n\n\n\n
What Do DMARC Policies None, Quarantine and Reject Actually Mean?<\/h2>\n\n\n\n
How the p=none Policy Monitors Email Without Enforcing Rejection<\/h3>\n\n\n\n
When to Move From Monitoring to the Quarantine Policy<\/h3>\n\n\n\n
How the Reject Policy Blocks Messages That Fail DMARC Evaluation<\/h3>\n\n\n\n
Understanding SPF and DKIM Alignment Requirements<\/h3>\n\n\n\n
Choosing Appropriate Enforcement Levels for Different Email Environments<\/h3>\n\n\n\n
How Can You Monitor DMARC Reports and Fix Email Authentication Failures?<\/h2>\n\n\n\n
Understanding Aggregate DMARC Reports and Their XML Structure<\/h3>\n\n\n\n
Identifying Legitimate Email Sources That Fail SPF or DKIM Alignment<\/h3>\n\n\n\n
Correcting Authentication Issues With Marketing and Transactional Email Platforms<\/h3>\n\n\n\n
Investigating Unauthorized Senders and Suspicious Email Sources<\/h3>\n\n\n\n
Verifying Email Authentication Through Message Headers and Testing Tools<\/h3>\n\n\n\n
How Can Small Businesses Maintain DMARC Without Disrupting Email Delivery?<\/h2>\n\n\n\n
Establishing a Gradual DMARC Enforcement Schedule<\/h3>\n\n\n\n
Reviewing New Email Services Before Authorizing Them to Send Domain Emails<\/h3>\n\n\n\n
Maintaining SPF Records Without Exceeding DNS Lookup Limits<\/h3>\n\n\n\n
Monitoring Subdomains and Separate Business Email Systems<\/h3>\n\n\n\n
Documenting DNS Changes and Reviewing DMARC Reports Regularly<\/h3>\n\n\n\n