DMARC (or \u2018Domain-based Message Authentication, Reporting and Conformance\u2019) is a system designed to strengthen your email security by making it significantly harder for spammers to hijack your domain and send email that appears to be coming from you and your domain without your knowledge or permission.<\/p>\n
DMARC has been in use now for a while and most larger mail providers including Microsoft, Google, and Yahoo all now require it in order to accept mail from a domain.<\/p>\n
It has two primary jobs. First, it works with your domain\u2019s existing SPF and DKIM records and instructs the world at large exactly what they should do when they detect a message that fails one or more of these other systems. Second, it provides those remote servers a channel to communicate back with you about what they\u2019ve detected and how they\u2019ve dealt with it \u2014 the \u2018R\u2019 in DMARC.<\/p>\n
Unlike SPF and DKIM, DMARC requires a bit of maintenance to use correctly. If installed incorrectly it can cause severe impacts to your email causing legitimate mail from your domain to be treated as spam and deleted, without your recipient ever knowing. This article is here to guide you on what we\u2019ve found to be the best way to set up DMARC so that you get all the security you\u2019d expect without harming your normal mail activities.<\/p>\n
Step 1) Get your SPF and DKIM Working<\/h2>\n
DMARC is an extension to SPF and DKIM, so if you don\u2019t have a working SPF and DKIM record yet, you\u2019ll need to get that working first.<\/p>\n We have a quick how-to guide on our Knowledge base for how to set up SPF and DKIM using the \u2019email deliverability\u2019 icon in cPanel<\/a>.<\/p>\n SPF (Sender Policy Framework) is a system that uses DNS to tell the world which machines are allowed to send email from your domain. Each domain gets its own SPF, and if you have multiple services that send email from your domain, they\u2019re all rolled-up into one<\/em> SPF record.<\/p>\n The default SPF record you get on one of our servers doesn\u2019t allow third-party mail services to send email from your domain. Any third-party service you use should be able to tell you what to add to your SPF record so that they can be authenticated. This is usually done by adding an \u201c+include:\u201d to your record.<\/p>\n The last thing to mention about SPF is that it has a \u2018softfail\u2019 mode. This makes it less-strict than a normal SPF record. We\u2019ll come back to this.<\/p>\n DKIM (DomainKeys Identified Mail) is a second authentication system that is a bit more granular. It works in conjunction with SPF, but one key difference is that each email service provider has their own DKIM key, sometimes more than one.<\/p>\n When you set up DKIM on a HostUpon server (or any other cPanel service) it will install a DKIM record for you but this key only authenticates messages that come from that cPanel server. If you use third-party mail services, they should also be able to provide you with their DKIM record so that messages they send can be signed using that separate key.<\/p>\n This means a domain can have one SPF, but multiple<\/em> DKIM keys. A message sent from your domain only has to be linked to one of these keys in order to be considered authentic.<\/p>\n You read that right. Your DMARC record shouldn\u2019t be set to the \u2018final\u2019 version immediately. If you do that you run some pretty high risk that you\u2019ll break your email in ways that could be hard to diagnose. Your first record will actually be a neutered record that only reports back to you without telling remote servers to do anything to emails that fails SPF or DKIM.<\/p>\n Without even taking into consideration that some mail services online are now requiring one, there are a couple reasons. DMARC fills a couple security holes in your email security that DKIM and SPF alone don\u2019t cover.<\/p>\n SPF is great for telling a remote server that a message didn\u2019t come from an authenticated source, but it doesn\u2019t protect you from email that is sent from a subdomain<\/em> of your domain. I\u2019ve personally encountered a couple examples of spear-phishing that used this exact hole to skip right past SPF and unless you were extremely<\/em> observant messages like this looked fairly legitimate.<\/p>\n Likewise DKIM is optional. Messages that are sent from a server without DKIM support aren\u2019t flagged as a false message automatically. DKIM only provides reinforcement to a message\u2019s reputation when it passes. A lack<\/em> of a DKIM signature in a message doesn\u2019t automatically fail that message.<\/p>\n DMARC covers both of these holes. When used properly it will tell remote servers to require<\/em> at least one of these (SPF and DKIM) to pass before a message is considered authentic, and it will also fail<\/em> any message that doesn\u2019t line up exactly with the domain.<\/p>\n There are a lot of elements involved in a full DMARC record. For details on exactly how to install a DMARC record on a cPanel server, and what each little option does, check our our knowledge base article all about DMARC<\/a>. That KB article has some tips on what your DMARC should have but this article will go into more detail.<\/p>\n Above all else, your first record should have your Policy set to \u2018none\u2019 and your subdomain policy should match. With P=none, DMARC is in safe-mode. It will still be used to check all your email\u2019s authentication, but no action will be taken beyond what SPF does on its own without the support of DMARC.<\/p>\n The Alignment settings should be set to \u2018strict\u2019 as well. Since we\u2019re in testing mode, we want to know if messages that should pass are failing SPF or DMARC checks.<\/p>\n You can install DMARC on a cPanel server using the \u2018zone editor\u2019 icon in the \u2018Domains\u2019 section. If you have one already, you can edit the one you have, or you can add a new one using the \u201c+Add\u201d button in the top right<\/p>\n If you send email from subdomains, you should install a set of SPF, DKIM, and DMARC records for each subdomain.<\/em> The root DMARC record will apply to any subdomain that doesn\u2019t already have its own DMARC record.<\/p>\n You should then specify an email address for both Aggregate reports, as well as Forensic Reports. You may need to set a custom email address up for this.<\/p>\n Unless you\u2019re using a mail service provider that explicitly does not use both SPF and DKIM (Mailchimp is a notable example \u2014 they only support DKIM) Then the recommended setting for Forensic reports is if \u2018Any Check Fails\u2019 (fo=1). This will mean that any message that fails either<\/em> SPF or DKIM will be reported back to you, even if the other check passed. This is useful for detecting when your SPF or DKIM is malfunctioning.<\/p>\n There\u2019s three main phases to fully securing your messages with DMARC. As we mentioned earlier, your first rule should be\u2026<\/p>\n With your policy set to \u2018none\u2019 your mail will be handled as if your DMARC record doesn\u2019t exist. Messages will be handled according to your existing SPF and DKIM settings, which means messages that fail *both* of these will likely not be delivered, but edge-cases will probably be delivered.<\/p>\n You should also set the SPF and DKIM alignments to \u2018strict\u2019 to make sure that DMARC knows it should be strict with both these systems.<\/p>\n There\u2019s one important exception though. While mail delivery patterns won\u2019t change, with a DMARC record mail servers will start watching and will take note of when a message *would* have been denied by DMARC. These will show up in the failure and aggregate reports that these external providers will send you.<\/p>\n This means your DMARC record should contain at *least* an aggregate reporting address, and it probably should have a forensic reporting address as well.<\/p>\n In this mode, you\u2019re looking for messages that you know you sent properly, but were flagged by DMARC. If you find any in your reports, you may need to adjust your SPF and DKIM rules to make sure those messages are authenticated properly.<\/p>\n If you don\u2019t spot any issues with mail delivery but your SPF is still set to \u2018softfail\u2019 this is a good time to upgrade it to full fail, by changing the \u201c~all\u201d bit at the end of the rule to \u201c-all\u201d.<\/p>\n After a little while (I\u2019d recommend at least a week, maybe a month) it\u2019s time to step it up to\u2026<\/p>\n In this mode, message that fail DMARC security will still be delivered however they won\u2019t be sent to the inbox, but will be flagged as spam. All the same aggregate and failure reports will be sent to you but now messages that should have been delivered will show up in spam folders instead of inboxes.<\/p>\n It\u2019s a lot like \u2018P=none\u2019 but now it\u2019ll be more obvious since now your recipient will be able to tell mail delivery issues are happening. We\u2019re also starting to take control over subdomains, including potential subdomains that don\u2019t exist. This is important for detecting when bad actors try to \u2018make up\u2019 an email address on a subdomain of your domain to try and slip past standard SPF.<\/p>\n Once you\u2019re sure all your normal mail activities are being sent correctly, it\u2019s time to push it up to\u2026<\/p>\n This will put DMARC into full active mode. Messages that fail DMARC will be actively rejected by mail server worldwide and you\u2019ll get reports of this in your aggregate and failure report addresses.<\/p>\n It\u2019s only in this mode that certain types of phishing messages from malicious actors will actually be denied delivery!<\/p>\n It\u2019s important to note that the default DMARC threshold is to only flag a message as a problem when \u2018all checks fail\u2019, that is when a message fails SPF and<\/em> when there\u2019s a broken or missing DKIM signature in the message. Not all mail senders use both mechanisms though. If any of the services you use for your outbound mail do not use both SPF and DKIM, you\u2019ll need to make sure your DMARC record is configured to only generate failures when \u201call checks fail\u201d (or \u2018FO=0\u2019 in the raw DMARC record).<\/p>\n If all of your mail vendors authenticate all messages with both DKIM and<\/em> SPF, then switching your setting to \u2018FO=1\u2019 (\u201cAny Checks Fail\u201d) will tighten your security just a bit more.<\/p>\n Even if you specify a forensic reporting address many of the larger mail providers will ignore this setting and only send aggregate reports. Take advantage of the forensic reports when you get them, but don\u2019t assume you\u2019ll always get a forensic report of a failure.<\/p>\n If you find that too much of your email is being quarantined when you first switch from a \u2018none\u2019 policy to \u2018quarantine\u2019 you can set the \u2018percent\u2019 setting to a value lower than 100, perhaps 10, or 25. This will limit the impact of your DMARC rule until you can iron out why your messages are being blocked. As you fix your SPF and DKIM rules to properly cover your messages you can ramp up the percentage. Keep watching your reporting addresses and react as needed if things change, but eventually you\u2019ll be able to get it back to 100%.<\/p>\n DMARC is a system designed to tell the world who is allowed to send email, and who isn\u2019t. Once you\u2019ve got your policy ramped all the way up to \u2018reject\u2019 it\u2019ll be very difficult for a spammer or scammer to send email that appears to come from any part of your domain.<\/p>\n \u00a0<\/p>\n<\/div>\n\n","protected":false},"excerpt":{"rendered":" DMARC (or \u2018Domain-based Message Authentication, Reporting and Conformance\u2019) is a system designed to strengthen your email security by making it significantly harder for spammers to hijack your domain and send email that appears to be coming from you and your domain without your knowledge or permission. DMARC has been in use now for a while […]<\/p>\n","protected":false},"author":1,"featured_media":320643,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[95],"tags":[59474,11109],"dealstore":[],"offerexpiration":[],"class_list":["post-320642","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-internet-business","tag-dmarc","tag-domain"],"yoast_head":"\n![\"\"](\"https:\/\/hostupon.com\/blog\/wp-content\/uploads\/2025\/08\/Email_deliverability_issues.png\")
<\/a>SPF<\/h3>\n
DKIM<\/h3>\n
Step 2) Your first DMARC record<\/h2>\n
Why Even Have a DMARC Though?<\/h3>\n
So what should your first DMARC look like?<\/h3>\n
<\/a>Step 3) Tightening the Rules<\/h2>\n
p=none; aspf=s; adkim=s<\/h3>\n
<\/a>p=quarantine; sp=quarantine<\/h3>\n
<\/a>p=reject; sp=reject<\/h3>\n
<\/a>Some Final Notes\u2026<\/h2>\n
Tuning DMARC to Handle Partial Failures<\/h3>\n
Not all Mail Providers Send Forensic Reports<\/h3>\n
Too Many Delivery Issues enabling P=quarantine?<\/h3>\n
And That\u2019s It!<\/h2>\n