{"id":4208,"date":"2026-01-05T16:22:36","date_gmt":"2026-01-05T13:22:36","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/dmarc-in-context-why-the-reports-matter-more-than-the-record\/"},"modified":"2026-01-05T16:22:36","modified_gmt":"2026-01-05T13:22:36","slug":"dmarc-in-context-why-the-reports-matter-more-than-the-record","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/dmarc-in-context-why-the-reports-matter-more-than-the-record\/","title":{"rendered":"DMARC in Context: Why the Reports Matter More Than the Record"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>{<br \/>\n  &#8220;title&#8221;: &#8220;How to Read DMARC Reports and Move Safely from None to Reject&#8221;,<br \/>\n  &#8220;content&#8221;: &#8220;<\/p>\n<p>DMARC is one of those DNS records that many teams add once and then ignore, until a partner complains their invoices are going to spam or your brand shows up in a phishing campaign. The power of DMARC is not just the policy (<code>p=none<\/code>, <code>quarantine<\/code>, <code>reject<\/code>) but the reports it sends back to you. Those reports tell you exactly who is sending email on behalf of your domain, how mailbox providers see those messages, and which flows will break the moment you enforce a strict policy. In this article we\u2019ll walk through how to read both aggregate and forensic DMARC reports and outline a practical, low\u2011risk path from <code>p=none<\/code> to <code>p=reject<\/code>. We\u2019ll keep it concrete with examples you can map to your own shared hosting, <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> or dedicated mail infrastructure at dchost.com, and we\u2019ll focus on what matters for deliverability and security instead of XML trivia.<\/p>\n<p>nnnn<\/p>\n<p>DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It answers three questions for receiving mail servers:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Is the message authenticated by SPF and\/or DKIM?<\/li>\n<p>n  <\/p>\n<li>Does the authenticated domain align with the visible From: domain?<\/li>\n<p>n  <\/p>\n<li>What does the domain owner want us to do if it doesn\u2019t align?<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>That last part is the DMARC policy:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li><strong>p=none<\/strong> \u2013 monitor only, no enforcement<\/li>\n<p>n  <\/p>\n<li><strong>p=quarantine<\/strong> \u2013 suspicious messages should go to spam\/junk<\/li>\n<p>n  <\/p>\n<li><strong>p=reject<\/strong> \u2013 suspicious messages should be rejected at SMTP<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>If you are new to SPF, DKIM and DMARC, it\u2019s worth first reading our practical guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/spf-dkim-ve-dmarc-nedir-ozel-alan-adi-ile-e-posta-dogrulamasini-cpanel-ve-vpste-sifirdan-kurmak\/\">explaining SPF, DKIM and DMARC setup on cPanel and VPS<\/a>. Once your records exist, the real work starts: reading and acting on the DMARC reports. Without that feedback loop, moving straight to <code>p=reject<\/code> is guesswork and can silently break legitimate email flows.<\/p>\n<p>nn<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#DMARC_Policy_and_Tags_The_Pieces_Behind_the_Reports\"><span class=\"toc_number toc_depth_1\">1<\/span> DMARC Policy and Tags: The Pieces Behind the Reports<\/a><\/li><li><a href=\"#Aggregate_DMARC_Reports_RUA_The_HighLevel_View\"><span class=\"toc_number toc_depth_1\">2<\/span> Aggregate DMARC Reports (RUA): The High\u2011Level View<\/a><ul><li><a href=\"#What_Aggregate_Reports_Look_Like\"><span class=\"toc_number toc_depth_2\">2.1<\/span> What Aggregate Reports Look Like<\/a><\/li><li><a href=\"#The_Columns_That_Actually_Matter\"><span class=\"toc_number toc_depth_2\">2.2<\/span> The Columns That Actually Matter<\/a><\/li><li><a href=\"#Example_Reading_an_Aggregate_Report_Row\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Example: Reading an Aggregate Report Row<\/a><\/li><li><a href=\"#Classifying_Sources_Legit_Misconfigured_or_Malicious\"><span class=\"toc_number toc_depth_2\">2.4<\/span> Classifying Sources: Legit, Misconfigured, or Malicious<\/a><\/li><li><a href=\"#Spotting_Forwarding_Problems\"><span class=\"toc_number toc_depth_2\">2.5<\/span> Spotting Forwarding Problems<\/a><\/li><\/ul><\/li><li><a href=\"#Forensic_DMARC_Reports_RUF_Deep_Dives_on_Individual_Failures\"><span class=\"toc_number toc_depth_1\">3<\/span> Forensic DMARC Reports (RUF): Deep Dives on Individual Failures<\/a><ul><li><a href=\"#What_Forensic_Reports_Are_and_When_They_Trigger\"><span class=\"toc_number toc_depth_2\">3.1<\/span> What Forensic Reports Are and When They Trigger<\/a><\/li><li><a href=\"#Privacy_and_Compliance_Considerations\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Privacy and Compliance Considerations<\/a><\/li><li><a href=\"#When_Forensic_Reports_Are_Actually_Useful\"><span class=\"toc_number toc_depth_2\">3.3<\/span> When Forensic Reports Are Actually Useful<\/a><\/li><\/ul><\/li><li><a href=\"#A_Practical_DMARC_Report_Reading_Workflow\"><span class=\"toc_number toc_depth_1\">4<\/span> A Practical DMARC Report Reading Workflow<\/a><ul><li><a href=\"#Step_1_Turn_On_Reporting_Without_Enforcement\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Step 1: Turn On Reporting (Without Enforcement)<\/a><\/li><li><a href=\"#Step_2_Let_Data_Accumulate\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Step 2: Let Data Accumulate<\/a><\/li><li><a href=\"#Step_3_Build_a_Sender_Inventory\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Step 3: Build a Sender Inventory<\/a><\/li><li><a href=\"#Step_4_Fix_Misconfigurations_Source_by_Source\"><span class=\"toc_number toc_depth_2\">4.4<\/span> Step 4: Fix Misconfigurations Source by Source<\/a><\/li><li><a href=\"#Step_5_Watch_Deliverability_and_Reputation_Signals\"><span class=\"toc_number toc_depth_2\">4.5<\/span> Step 5: Watch Deliverability and Reputation Signals<\/a><\/li><\/ul><\/li><li><a href=\"#Safe_Path_from_pnone_to_preject\"><span class=\"toc_number toc_depth_1\">5<\/span> Safe Path from p=none to p=reject<\/a><ul><li><a href=\"#Phase_1_Baseline_with_pnone_Monitoring_Only\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Phase 1 \u2013 Baseline with p=none (Monitoring Only)<\/a><\/li><li><a href=\"#Phase_2_Introduce_Quarantine_with_a_Low_pct\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Phase 2 \u2013 Introduce Quarantine with a Low pct<\/a><\/li><li><a href=\"#Phase_3_Increase_Coverage_and_Move_to_Reject\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Phase 3 \u2013 Increase Coverage and Move to Reject<\/a><\/li><li><a href=\"#Subdomains_and_Separate_Sending_Domains\"><span class=\"toc_number toc_depth_2\">5.4<\/span> Subdomains and Separate Sending Domains<\/a><\/li><li><a href=\"#BIMI_MTASTS_and_Other_Advanced_Extras\"><span class=\"toc_number toc_depth_2\">5.5<\/span> BIMI, MTA\u2011STS and Other Advanced Extras<\/a><\/li><\/ul><\/li><li><a href=\"#HostingSide_Considerations_DNS_IPs_and_Infrastructure\"><span class=\"toc_number toc_depth_1\">6<\/span> Hosting\u2011Side Considerations: DNS, IPs and Infrastructure<\/a><ul><li><a href=\"#Where_to_Manage_DMARC_DNS\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Where to Manage DMARC DNS<\/a><\/li><li><a href=\"#Reverse_DNS_IPv6_and_Shared_vs_Dedicated_IPs\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Reverse DNS, IPv6 and Shared vs Dedicated IPs<\/a><\/li><\/ul><\/li><li><a href=\"#Wrapping_Up_DMARC_Reports_as_an_Ongoing_Feedback_Loop\"><span class=\"toc_number toc_depth_1\">7<\/span> Wrapping Up: DMARC Reports as an Ongoing Feedback Loop<\/a><\/li><\/ul><\/div>\n<h2><span id=\"DMARC_Policy_and_Tags_The_Pieces_Behind_the_Reports\">DMARC Policy and Tags: The Pieces Behind the Reports<\/span><\/h2>\n<p>nn<\/p>\n<p>A DMARC record is a TXT record at <code>_dmarc.yourdomain.com<\/code>. A typical starting point looks like this:<\/p>\n<p>nn<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">_dmarc.yourdomain.com.  IN TXT  &quot;v=DMARC1; p=none; rua=mailto:dmarc-rua@yourdomain.com; ruf=mailto:dmarc-ruf@yourdomain.com; fo=1; adkim=s; aspf=s&quot;n<\/code><\/pre>\n<p>nn<\/p>\n<p>Key tags you\u2019ll see referenced in reports:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li><strong>v<\/strong> \u2013 protocol version (<code>DMARC1<\/code>)<\/li>\n<p>n  <\/p>\n<li><strong>p<\/strong> \u2013 policy for the organizational domain (<code>none<\/code>, <code>quarantine<\/code>, <code>reject<\/code>)<\/li>\n<p>n  <\/p>\n<li><strong>sp<\/strong> \u2013 optional policy for subdomains (defaults to <code>p<\/code> when omitted)<\/li>\n<p>n  <\/p>\n<li><strong>pct<\/strong> \u2013 percentage of messages to which the policy applies (0\u2013100)<\/li>\n<p>n  <\/p>\n<li><strong>rua<\/strong> \u2013 addresses to receive <strong>aggregate<\/strong> DMARC reports (RUA)<\/li>\n<p>n  <\/p>\n<li><strong>ruf<\/strong> \u2013 addresses to receive <strong>forensic<\/strong> \/ failure reports (RUF)<\/li>\n<p>n  <\/p>\n<li><strong>fo<\/strong> \u2013 failure reporting options (forensic triggering rules)<\/li>\n<p>n  <\/p>\n<li><strong>adkim<\/strong> \u2013 DKIM alignment mode (<code>r<\/code> relaxed, <code>s<\/code> strict)<\/li>\n<p>n  <\/p>\n<li><strong>aspf<\/strong> \u2013 SPF alignment mode (<code>r<\/code> relaxed, <code>s<\/code> strict)<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>The important part for report reading is that mailbox providers will send XML files to your <code>rua<\/code> (aggregate) and sometimes <code>ruf<\/code> (forensic) addresses. Those XML files contain:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Which IPs sent email using your domain<\/li>\n<p>n  <\/p>\n<li>How many messages each IP sent within a time window<\/li>\n<p>n  <\/p>\n<li>SPF, DKIM and DMARC pass\/fail and alignment status<\/li>\n<p>n  <\/p>\n<li>How the receiver treated those messages, based on your policy<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>Think of DMARC as an analytics layer for your outbound email. It\u2019s the email equivalent of web server logs: raw, sometimes ugly, but incredibly powerful once you know where to look. We\u2019ve written before about why <a href=\"https:\/\/www.dchost.com\/blog\/en\/inbox-dan-spam-a-dostane-kadar-spf-dkim-dmarc-ve-rdns-ile-e-posta-teslim-edilebilirligini-nasil-adim-adim-yukseltirsin\/\">proper SPF\/DKIM\/DMARC and rDNS are essential for staying out of spam<\/a>; DMARC reports are how you verify that configuration in the real world.<\/p>\n<p>nn<\/p>\n<h2><span id=\"Aggregate_DMARC_Reports_RUA_The_HighLevel_View\">Aggregate DMARC Reports (RUA): The High\u2011Level View<\/span><\/h2>\n<p>nn<\/p>\n<h3><span id=\"What_Aggregate_Reports_Look_Like\">What Aggregate Reports Look Like<\/span><\/h3>\n<p>nn<\/p>\n<p>Aggregate reports (often called RUA reports) are XML files typically sent once per day per receiver (e.g. one from each major mailbox provider). They summarize all email claiming to be from your domain during that period.<\/p>\n<p>nn<\/p>\n<p>The main sections inside each XML are:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li><strong>&lt;report_metadata&gt;<\/strong> \u2013 who sent the report, ID, date range<\/li>\n<p>n  <\/p>\n<li><strong>&lt;policy_published&gt;<\/strong> \u2013 the DMARC record the receiver saw (p, sp, pct, adkim, aspf)<\/li>\n<p>n  <\/p>\n<li><strong>&lt;record&gt;<\/strong> blocks \u2013 one per source (IP + sender domain combination) with:\n<ul>n      <\/p>\n<li><strong>&lt;row&gt;<\/strong> \u2013 message count and DMARC evaluation result<\/li>\n<p>n      <\/p>\n<li><strong>&lt;identifiers&gt;<\/strong> \u2013 the envelope and header domains<\/li>\n<p>n      <\/p>\n<li><strong>&lt;auth_results&gt;<\/strong> \u2013 detailed SPF and DKIM results<\/li>\n<p>n    <\/ul>\n<p>n  <\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>You don\u2019t have to become an XML expert. In practice you\u2019ll either:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Feed these XML files to a DMARC analysis tool (self\u2011hosted or third\u2011party), or<\/li>\n<p>n  <\/p>\n<li>Convert them with a simple script and open the CSV in a spreadsheet or BI tool<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>If you already centralize other logs, you can also push DMARC data into the same stack (for example into an ELK or Loki\/Grafana environment similar to the one we describe in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/birden-fazla-sunucuda-log-yonetimi-elk-ve-loki-stack-ile-merkezi-hosting-loglama\/\">centralized log management across multiple servers<\/a>).<\/p>\n<p>nn<\/p>\n<h3><span id=\"The_Columns_That_Actually_Matter\">The Columns That Actually Matter<\/span><\/h3>\n<p>nn<\/p>\n<p>Regardless of how you view the data, focus on these key fields for each source:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li><strong>Source IP<\/strong> \u2013 where the email actually originated<\/li>\n<p>n  <\/p>\n<li><strong>Count<\/strong> \u2013 how many messages from that source in the report period<\/li>\n<p>n  <\/p>\n<li><strong>Header From domain<\/strong> \u2013 the visible From: your users see<\/li>\n<p>n  <\/p>\n<li><strong>SPF result &amp; domain<\/strong> \u2013 did SPF pass, and which domain?<\/li>\n<p>n  <\/p>\n<li><strong>DKIM result &amp; domain<\/strong> \u2013 did DKIM pass, and which domain?<\/li>\n<p>n  <\/p>\n<li><strong>DMARC disposition<\/strong> \u2013 none, quarantine, reject (how the receiver treated it)<\/li>\n<p>n  <\/p>\n<li><strong>Alignment<\/strong> \u2013 whether SPF and\/or DKIM were aligned with the Header From<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>Alignment is the heart of DMARC. A message only <em>passes<\/em> DMARC if:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>At least one of SPF or DKIM passes, and<\/li>\n<p>n  <\/p>\n<li>The authenticated domain (from SPF or DKIM) aligns with the From: domain according to your <code>aspf<\/code> and <code>adkim<\/code> settings<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<h3><span id=\"Example_Reading_an_Aggregate_Report_Row\">Example: Reading an Aggregate Report Row<\/span><\/h3>\n<p>nn<\/p>\n<p>Imagine a simplified record in your RUA data:<\/p>\n<p>nn<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">Source IP: 203.0.113.10nCount: 428nHeader From: yourdomain.comnSPF: pass (smtp.mail.your-marketing-tool.com)nDKIM: pass (news.yourdomain.com)nDMARC: pass (DKIM aligned, SPF not aligned)n<\/code><\/pre>\n<p>nn<\/p>\n<p>What does this tell you?<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>A third\u2011party marketing platform is sending 428 messages using <code>From: yourdomain.com<\/code>.<\/li>\n<p>n  <\/p>\n<li>SPF passes but from the vendor\u2019s domain, so it doesn\u2019t align with your domain.<\/li>\n<p>n  <\/p>\n<li>DKIM passes from <code>news.yourdomain.com<\/code> and aligns (assuming <code>adkim=r<\/code> or <code>s<\/code> with matching org domain).<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>In this case, DMARC passes thanks to aligned DKIM. When you move towards <code>p=reject<\/code>, this flow is safe <em>as long as<\/em> you keep the DKIM configuration intact. If an engineer disables DKIM for that provider later, DMARC will start failing and reports will show <code>fail<\/code> for both SPF and DKIM alignment.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Classifying_Sources_Legit_Misconfigured_or_Malicious\">Classifying Sources: Legit, Misconfigured, or Malicious<\/span><\/h3>\n<p>nn<\/p>\n<p>The first big task when you start reading DMARC reports is to group sources into three buckets:<\/p>\n<p>nn<\/p>\n<ol>n  <\/p>\n<li><strong>Legitimate and correctly authenticated<\/strong>n\n<ul>n      <\/p>\n<li>Examples: your main mail server, CRM, helpdesk platform, newsletter provider<\/li>\n<p>n      <\/p>\n<li>Action: document them and ensure at least one of SPF or DKIM is aligned for each<\/li>\n<p>n    <\/ul>\n<p>n  <\/li>\n<p>n  <\/p>\n<li><strong>Legitimate but misconfigured<\/strong>n\n<ul>n      <\/p>\n<li>Examples: a small SaaS tool sending invoices, a legacy on\u2011premise system relaying directly with your domain in From:<\/li>\n<p>n      <\/p>\n<li>Action: either add them to SPF and ensure alignment, or enable DKIM on that sender<\/li>\n<p>n    <\/ul>\n<p>n  <\/li>\n<p>n  <\/p>\n<li><strong>Unknown or malicious<\/strong>n\n<ul>n      <\/p>\n<li>Examples: random IPs in hosting ranges you\u2019ve never used, foreign ISPs<\/li>\n<p>n      <\/p>\n<li>Action: do nothing on your infrastructure; tightening DMARC will cause these to be quarantined or rejected<\/li>\n<p>n    <\/ul>\n<p>n  <\/li>\n<p>n<\/ol>\n<p>nn<\/p>\n<p>Most organizations discover at least one \u201cforgotten\u201d sender this way\u2014maybe a marketing tool or legacy ERP. DMARC reports bring those to light so you can fix them before enforcement.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Spotting_Forwarding_Problems\">Spotting Forwarding Problems<\/span><\/h3>\n<p>nn<\/p>\n<p>Forwarding is a common source of confusion. When a user forwards mail from <code>user@yourdomain.com<\/code> to another mailbox, SPF can break because the forwarder\u2019s IP is not in your SPF record, even though the message is legitimate. This may appear in DMARC reports as:<\/p>\n<p>nn<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">SPF: fail (not authorized)nDKIM: pass (aligned)nDMARC: pass (DKIM aligned)n<\/code><\/pre>\n<p>nn<\/p>\n<p>This is normal: DKIM survives forwarding as long as the signature isn\u2019t modified. Where you see SPF failure but DKIM alignment, you usually don\u2019t need to change anything. If you see both SPF and DKIM failing after forwarding, that\u2019s where modern techniques like SRS (Sender Rewriting Scheme) and ARC (Authenticated Received Chain) come into play. We explain these in detail in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/e%e2%80%91posta-yonlendirmede-spf-dmarc-neden-kiriliyor-srs-ve-arc-ile-nasil-tatli-tatli-onarirsin\/\">how SRS and ARC fix SPF\/DMARC breakage during email forwarding<\/a>.<\/p>\n<p>nn<\/p>\n<h2><span id=\"Forensic_DMARC_Reports_RUF_Deep_Dives_on_Individual_Failures\">Forensic DMARC Reports (RUF): Deep Dives on Individual Failures<\/span><\/h2>\n<p>nn<\/p>\n<h3><span id=\"What_Forensic_Reports_Are_and_When_They_Trigger\">What Forensic Reports Are and When They Trigger<\/span><\/h3>\n<p>nn<\/p>\n<p>Forensic (RUF) reports are different: instead of a daily summary, they are near\u2011real\u2011time reports about individual messages that failed DMARC. Depending on your <code>fo<\/code> setting, they may include headers only or parts of the message body (often redacted).<\/p>\n<p>nn<\/p>\n<p>Common <code>fo<\/code> options:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li><strong>fo=0<\/strong> \u2013 send reports if both SPF and DKIM fail to produce aligned results<\/li>\n<p>n  <\/p>\n<li><strong>fo=1<\/strong> \u2013 send reports if <em>either<\/em> SPF or DKIM shows a failure<\/li>\n<p>n  <\/p>\n<li><strong>fo=d<\/strong> \u2013 send reports if DKIM fails<\/li>\n<p>n  <\/p>\n<li><strong>fo=s<\/strong> \u2013 send reports if SPF fails<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>We generally recommend starting carefully, for example with <code>fo=1<\/code> but RUF pointing to a dedicated, access\u2011controlled mailbox so that sensitive content doesn\u2019t mix into normal email.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Privacy_and_Compliance_Considerations\">Privacy and Compliance Considerations<\/span><\/h3>\n<p>nn<\/p>\n<p>Because forensic reports can contain snippets of message content or full headers, they may reveal personal data (names, email addresses, sometimes subject lines). That means they should be treated like any other log data under regulations such as GDPR or KVKK. If your legal or compliance team has rules for <a href=\"https:\/\/www.dchost.com\/blog\/en\/hosting-ve-e-posta-altyapisinda-log-saklama-sureleri\/\">log retention on hosting and email infrastructure<\/a>, apply the same thinking to RUF storage:<\/p>\n<p>nn<\/p>\n<ul>n  <\/p>\n<li>Store RUF data in a restricted mailbox or log store<\/li>\n<p>n  <\/p>\n<li>Set clear retention periods (e.g. 30\u201390 days)<\/li>\n<p>n  <\/p>\n<li>Limit access to security\/infra staff<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>If that feels like too much overhead initially, it\u2019s completely fine to skip RUF in your first DMARC phase and rely solely on aggregate reports.<\/p>\n<p>nn<\/p>\n<h3><span id=\"When_Forensic_Reports_Are_Actually_Useful\">When Forensic Reports Are Actually Useful<\/span><\/h3>\n<p>nn<\/p>\n<p>Forensic reports shine in three scenarios:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li><strong>Investigating active abuse<\/strong> \u2013 If your brand is being spoofed, RUF samples show how attackers structure their messages and which sending IPs are involved.<\/li>\n<p>n  <\/p>\n<li><strong>Debugging tricky flows<\/strong> \u2013 For rare or edge-case failures, seeing the full headers of a failing message is far more efficient than guessing from aggregates.<\/li>\n<p>n  <\/p>\n<li><strong>Validating enforcement<\/strong> \u2013 After moving to <code>p=quarantine<\/code> or <code>p=reject<\/code>, RUF can confirm that suspicious messages are indeed failing and being handled as intended.<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>Just don\u2019t rely on RUF volume to understand overall health; aggregate RUA data is the main source of truth for trends and coverage.<\/p>\n<p>nn<\/p>\n<h2><span id=\"A_Practical_DMARC_Report_Reading_Workflow\">A Practical DMARC Report Reading Workflow<\/span><\/h2>\n<p>nn<\/p>\n<h3><span id=\"Step_1_Turn_On_Reporting_Without_Enforcement\">Step 1: Turn On Reporting (Without Enforcement)<\/span><\/h3>\n<p>nn<\/p>\n<p>Start with a DMARC record that enables reporting but doesn\u2019t affect delivery:<\/p>\n<p>nn<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">v=DMARC1; p=none; rua=mailto:dmarc-rua@yourdomain.com; fo=1; adkim=r; aspf=rn<\/code><\/pre>\n<p>nn<\/p>\n<p>Use a dedicated mailbox for RUA (and optionally RUF) so that DMARC data doesn\u2019t clutter user inboxes. Configure this TXT record via your dchost.com DNS panel or your control panel (cPanel, DirectAdmin, or a DNS zone on your VPS\/<a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>).<\/p>\n<p>nn<\/p>\n<h3><span id=\"Step_2_Let_Data_Accumulate\">Step 2: Let Data Accumulate<\/span><\/h3>\n<p>nn<\/p>\n<p>Wait at least 1\u20132 weeks, ideally 30 days, to gather a representative sample\u2014especially if you have low\u2011volume transactional email like password resets, or irregular campaigns. During this period:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Collect daily RUA XML files from major receivers<\/li>\n<p>n  <\/p>\n<li>Feed them into your chosen analysis method (tool, script, spreadsheet, SIEM)<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<h3><span id=\"Step_3_Build_a_Sender_Inventory\">Step 3: Build a Sender Inventory<\/span><\/h3>\n<p>nn<\/p>\n<p>From the aggregate data, build an inventory:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Group by <strong>Header From<\/strong> domain (e.g. <code>yourdomain.com<\/code>, <code>news.yourdomain.com<\/code>)<\/li>\n<p>n  <\/p>\n<li>Within each, group by <strong>source IP<\/strong> and <strong>sending service<\/strong><\/li>\n<p>n  <\/p>\n<li>Label each source as:\n<ul>n      <\/p>\n<li><strong>Primary mail infrastructure<\/strong> (your own mail server, MTA on your VPS\/dedicated)<\/li>\n<p>n      <\/p>\n<li><strong>Third\u2011party platforms<\/strong> (CRM, newsletters, support desk, marketing tools)<\/li>\n<p>n      <\/p>\n<li><strong>Unknown\/malicious<\/strong><\/li>\n<p>n    <\/ul>\n<p>n  <\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>Cross\u2011check this inventory with your internal documentation. Many teams discover an extra tool sending \u201csystem notifications\u201d or a legacy device configured with their main domain as From: but no authentication.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Step_4_Fix_Misconfigurations_Source_by_Source\">Step 4: Fix Misconfigurations Source by Source<\/span><\/h3>\n<p>nn<\/p>\n<p>For each legitimate sender with DMARC failures:<\/p>\n<p>nn<\/p>\n<ul>n  <\/p>\n<li><strong>If SPF fails or isn\u2019t aligned:<\/strong>n\n<ul>n      <\/p>\n<li>Add or correct the sender\u2019s IP\/domain in your SPF record (within the 10\u2011lookup limit)<\/li>\n<p>n      <\/p>\n<li>Ensure the <code>Mail From<\/code> \/ envelope domain used by that sender aligns with the Header From domain if you rely on SPF for DMARC alignment<\/li>\n<p>n      <\/p>\n<li>If your SPF record is getting complex, our guide to <a href=\"https:\/\/www.dchost.com\/blog\/en\/gelismis-spf-yonetimi-10-dns-lookup-limitine-takilmadan-coklu-e-posta-servisi-kullanmak\/\">advanced SPF management without hitting the 10 DNS lookup limit<\/a> will help keep it maintainable.<\/li>\n<p>n    <\/ul>\n<p>n  <\/li>\n<p>n  <\/p>\n<li><strong>If DKIM fails or isn\u2019t aligned:<\/strong>n\n<ul>n      <\/p>\n<li>Enable DKIM signing on that platform<\/li>\n<p>n      <\/p>\n<li>Publish the DKIM public key under the selector they specify<\/li>\n<p>n      <\/p>\n<li>Make sure the DKIM signing domain (d=) aligns with your From: domain<\/li>\n<p>n    <\/ul>\n<p>n  <\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>Re-check DMARC reports after every change. You should see DMARC pass rates increase for those sources within a day or two.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Step_5_Watch_Deliverability_and_Reputation_Signals\">Step 5: Watch Deliverability and Reputation Signals<\/span><\/h3>\n<p>nn<\/p>\n<p>While tuning DMARC, keep an eye on:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Bounce codes and SMTP errors (especially 550\/5.7.x related to policy)<\/li>\n<p>n  <\/p>\n<li>Open\/click rates in your email tools<\/li>\n<p>n  <\/p>\n<li>Spam complaints and user feedback<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>Combine DMARC visibility with the deliverability checklist we outlined in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/spf-dkim-dmarc-ve-rdns-ile-e-posta-teslim-edilebilirligini-nasil-adim-adim-yukseltirsin\/\">keeping your emails out of spam using SPF, DKIM, DMARC and rDNS<\/a>. If you\u2019re also warming up a new dedicated IP for outbound mail, our guide to <a href=\"https:\/\/www.dchost.com\/blog\/en\/dedicated-ip-isitma-ve-e-posta-itibari-yonetimi\/\">dedicated IP warmup and reputation management<\/a> pairs nicely with DMARC adoption.<\/p>\n<p>nn<\/p>\n<h2><span id=\"Safe_Path_from_pnone_to_preject\">Safe Path from p=none to p=reject<\/span><\/h2>\n<p>nn<\/p>\n<h3><span id=\"Phase_1_Baseline_with_pnone_Monitoring_Only\">Phase 1 \u2013 Baseline with p=none (Monitoring Only)<\/span><\/h3>\n<p>nn<\/p>\n<p>Stay on <code>p=none<\/code> until:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>You have a complete inventory of all legitimate senders<\/li>\n<p>n  <\/p>\n<li>Each has at least one aligned authentication method (SPF or DKIM)<\/li>\n<p>n  <\/p>\n<li>Aggregate DMARC reports show a high DMARC pass rate (e.g. &gt;95% of legitimate mail)<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>At this stage, you may already lower risk from abuse because many mailbox providers start treating aligned DMARC as a positive signal even before you enforce.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Phase_2_Introduce_Quarantine_with_a_Low_pct\">Phase 2 \u2013 Introduce Quarantine with a Low pct<\/span><\/h3>\n<p>nn<\/p>\n<p>Once you\u2019re confident, you can start asking receivers to quarantine some failing messages, but not all:<\/p>\n<p>nn<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-rua@yourdomain.com; fo=1; adkim=s; aspf=sn<\/code><\/pre>\n<p>nn<\/p>\n<p>Key points in this step:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li><strong>p=quarantine<\/strong> tells receivers to treat failing messages as suspicious, usually spam folder.<\/li>\n<p>n  <\/p>\n<li><strong>pct=10<\/strong> limits this to 10% of failing messages. This gives you a safety net.<\/li>\n<p>n  <\/p>\n<li><strong>adkim=s and aspf=s<\/strong> tighten alignment (strict mode). You can keep them relaxed (<code>r<\/code>) if you have complex subdomain setups, but strict alignment makes your brand harder to spoof.<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>Monitor DMARC reports closely for 2\u20134 weeks:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>Did any legitimate flows start failing and being quarantined?<\/li>\n<p>n  <\/p>\n<li>Are failure sources mostly unknown\/malicious?<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>If you see legitimate mail failing, go back to Phase 1 troubleshooting: fix SPF\/DKIM, then carry on.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Phase_3_Increase_Coverage_and_Move_to_Reject\">Phase 3 \u2013 Increase Coverage and Move to Reject<\/span><\/h3>\n<p>nn<\/p>\n<p>Assuming the small\u2011percentage quarantine goes smoothly, gradually increase <code>pct<\/code> to 50, then 100 over several weeks, each time verifying in your reports that legitimate senders remain green.<\/p>\n<p>nn<\/p>\n<p>When you\u2019re ready for full enforcement, update the record:<\/p>\n<p>nn<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-rua@yourdomain.com; fo=1; adkim=s; aspf=sn<\/code><\/pre>\n<p>nn<\/p>\n<p>Now, receivers are asked to outright reject messages that fail DMARC. Your aggregate reports will still show those attempts, but with <code>disposition=reject<\/code>. This is where DMARC becomes a strong anti\u2011spoofing control: it\u2019s extremely difficult for attackers to send mail that appears to be from your domain and passes DMARC unless they compromise a legitimate sending system or private key.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Subdomains_and_Separate_Sending_Domains\">Subdomains and Separate Sending Domains<\/span><\/h3>\n<p>nn<\/p>\n<p>Many organizations use subdomains or separate domains for different email flows. For example:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li><code>yourdomain.com<\/code> \u2013 corporate mail and high\u2011trust communication<\/li>\n<p>n  <\/p>\n<li><code>news.yourdomain.com<\/code> \u2013 newsletters and marketing<\/li>\n<p>n  <\/p>\n<li><code>billing.yourdomain.com<\/code> \u2013 invoices and transactional emails<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>DMARC lets you set different policies for subdomains using the <code>sp=<\/code> tag or standalone DMARC records at each subdomain. For high\u2011risk corporate mail, you might want <code>p=reject<\/code> on the apex domain, while keeping more flexible policies on marketing subdomains. We discussed the pros and cons of using separate sending domains for transactional vs marketing email in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/e-posta-icin-ayri-gonderim-alan-adi-kullanmak-transactional-ve-pazarlama-e-postalari-icin-dogru-domain-ve-dns-stratejisi\/\">separate domains for transactional and marketing emails<\/a>; DMARC policies are a key part of that architecture.<\/p>\n<p>nn<\/p>\n<h3><span id=\"BIMI_MTASTS_and_Other_Advanced_Extras\">BIMI, MTA\u2011STS and Other Advanced Extras<\/span><\/h3>\n<p>nn<\/p>\n<p>Once you reach <code>p=quarantine<\/code> or <code>p=reject<\/code>, you unlock extra ecosystem features like BIMI (Brand Indicators for Message Identification), which can display your logo next to messages in some providers. You also have a stronger basis to deploy MTA\u2011STS, TLS\u2011RPT and even DANE\/TLSA for transport\u2011layer security. We explored these advanced DNS\/email settings in our deep dive on <a href=\"https:\/\/www.dchost.com\/blog\/en\/mta-sts-tls-rpt-ve-bimi-nedir-e-posta-guvenligi-ve-marka-gorunurlugu-icin-gelismis-dns-ayarlari\/\">MTA\u2011STS, TLS\u2011RPT and BIMI for safer email and stronger brands<\/a>, and in our DMARC\u2011focused playbook <a href=\"https:\/\/www.dchost.com\/blog\/en\/gelismis-dmarc-ve-bimi-rua-ruf-raporlarindan-marka-gostergesine-nasil-yol-alinir\/\">beyond p=none with advanced DMARC and BIMI<\/a>.<\/p>\n<p>nn<\/p>\n<h2><span id=\"HostingSide_Considerations_DNS_IPs_and_Infrastructure\">Hosting\u2011Side Considerations: DNS, IPs and Infrastructure<\/span><\/h2>\n<p>nn<\/p>\n<h3><span id=\"Where_to_Manage_DMARC_DNS\">Where to Manage DMARC DNS<\/span><\/h3>\n<p>nn<\/p>\n<p>Your DMARC record lives in DNS, so you can manage it wherever your DNS is hosted:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li>dchost.com nameservers with our domain and hosting services<\/li>\n<p>n  <\/p>\n<li>The DNS zone inside your cPanel\/DirectAdmin account<\/li>\n<p>n  <\/p>\n<li>A DNS server on your VPS, dedicated or colocated server<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>Just make sure you have a clear DNS authority model so you\u2019re not editing old or unused zones. If you\u2019re migrating domains or DNS, follow the steps in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/alan-adi-nasil-transfer-edilir-epp-kodu-transfer-kilidi-ve-kesintisiz-gecise-sakin-bir-rehber\/\">transferring a domain without downtime<\/a> to avoid accidentally losing your DMARC and other TXT records.<\/p>\n<p>nn<\/p>\n<h3><span id=\"Reverse_DNS_IPv6_and_Shared_vs_Dedicated_IPs\">Reverse DNS, IPv6 and Shared vs Dedicated IPs<\/span><\/h3>\n<p>nn<\/p>\n<p>DMARC works best when it\u2019s part of a clean overall email posture:<\/p>\n<p>n<\/p>\n<ul>n  <\/p>\n<li><strong>Reverse DNS (PTR)<\/strong> should match your sending hostname; we covered the details in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ptr-reverse-dns-kaydi-vps-ipniz-icin-dogru-ayar-ve-e-posta-teslimine-etkisi\/\">PTR (reverse DNS) records<\/a>.<\/li>\n<p>n  <\/p>\n<li>If you send over IPv6, ensure proper SPF, PTR and DMARC alignment there too; see our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ipv6-ile-e-posta-gonderimi-reverse-dns-spf-ve-teslim-edilebilirlik-rehberi\/\">sending email over IPv6 and deliverability<\/a>.<\/li>\n<p>n  <\/p>\n<li>On shared hosting, your IP is shared with other customers; on a VPS or dedicated server with dchost.com, you can control the full email reputation story (SPF, rDNS, DMARC and rate limits) from end to end.<\/li>\n<p>n<\/ul>\n<p>nn<\/p>\n<p>For high\u2011volume transactional or marketing email, we usually recommend a VPS or dedicated server so you can tune outbound limits and monitor abuse closely, similar to the strategies we outlined in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hosting-ve-vpste-outbound-e-posta-guvenligi-ve-smtp-rate-limit-yonetimi\/\">outbound email security and SMTP rate limit management on shared hosting and VPS<\/a>.<\/p>\n<p>nn<\/p>\n<h2><span id=\"Wrapping_Up_DMARC_Reports_as_an_Ongoing_Feedback_Loop\">Wrapping Up: DMARC Reports as an Ongoing Feedback Loop<\/span><\/h2>\n<p>nn<\/p>\n<p>DMARC is not a one\u2011time DNS change; it\u2019s an ongoing feedback loop between your domain and the world\u2019s mail servers. Aggregate reports show you who is sending on your behalf and how well authenticated those messages are. Forensic reports, when used carefully, help debug tricky failures and investigate abuse. Together, they give you the confidence to move from a monitoring\u2011only policy (<code>p=none<\/code>) to enforcement (<code>p=quarantine<\/code> and ultimately <code>p=reject<\/code>) without breaking legitimate flows.<\/p>\n<p>nn<\/p>\n<p>At dchost.com, we see DMARC as part of a bigger picture: clean DNS, correct SPF and DKIM, proper reverse DNS, sensible rate limits and a hosting stack\u2014shared, VPS, dedicated or colocation\u2014that you fully understand. If you\u2019re planning a DMARC rollout or tightening your existing policy, our team can help you choose the right hosting architecture for your email, configure DNS records on our platform, and design a staged move from <code>p=none<\/code> to <code>p=reject<\/code> that protects your brand without surprises. Start by enabling DMARC reports today, spend a few weeks really reading them, and then we can harden your policy together, one safe step at a time.<\/p>\n<p>n&#8221;,<br \/>\n  &#8220;focus_keyword&#8221;: &#8220;how to read DMARC reports&#8221;,<br \/>\n  &#8220;meta_description&#8221;: &#8220;Learn how to read DMARC aggregate and forensic reports and move safely from p=none to p=reject without breaking legitimate email delivery.&#8221;,<br \/>\n  &#8220;faqs&#8221;: [<br \/>\n    {<br \/>\n      &#8220;question&#8221;: &#8220;How often should I review DMARC aggregate reports?&#8221;,<br \/>\n      &#8220;answer&#8221;: &#8220;In the early stages (when you are still on p=none or starting quarantine), review DMARC aggregate reports at least weekly, and ideally after every significant change to SPF, DKIM or sending infrastructure. Once you have a stable p=reject policy and a high DMARC pass rate, you can move to a monthly review cadence, with alerts for sudden spikes in failures or new unknown sources. Many teams also schedule a quarterly deeper review to catch new third\u2011party tools that may have started using the domain for email.&#8221;<br \/>\n    },<br \/>\n    {<br \/>\n      &#8220;question&#8221;: &#8220;Do I really need DMARC forensic (RUF) reports, or are aggregate reports enough?&#8221;,<br \/>\n      &#8220;answer&#8221;: &#8220;For most organizations, aggregate (RUA) reports are the primary tool for planning and enforcing DMARC. They give you the big picture: all sources, volumes and pass\/fail rates. Forensic (RUF) reports are optional but very helpful when you need to debug specific failures or investigate active abuse. Because RUF may contain message headers or content snippets, they should be handled carefully from a privacy and compliance perspective. A practical approach is to start with RUA only, then enable RUF later for a limited time or for security investigations.&#8221;<br \/>\n    },<br \/>\n    {<br \/>\n      &#8220;question&#8221;: &#8220;How long does it take to move safely from p=none to p=reject?&#8221;,<br \/>\n      &#8220;answer&#8221;: &#8220;For a small or medium environment with a handful of sending systems, a realistic timeline is 1\u20133 months. Spend the first 2\u20134 weeks on p=none gathering DMARC data and fixing SPF\/DKIM alignment for all legitimate senders. Then introduce p=quarantine with a low pct (10\u201325%) and watch reports for another 2\u20134 weeks. If everything remains stable, gradually raise pct to 100% and finally switch to p=reject. Large organizations with many third\u2011party tools may need longer, but the principle stays the same: don\u2019t advance to the next step until your DMARC reports show a consistently high pass rate for legitimate traffic.&#8221;<br \/>\n    },<br \/>\n    {<br \/>\n      &#8220;question&#8221;: &#8220;What should I do if DMARC reports show legitimate email failing?&#8221;,<br \/>\n      &#8220;answer&#8221;: &#8220;First, identify which system or provider is responsible by looking at the source IP and any identifying hostnames in the DMARC report. Then check whether SPF and\/or DKIM are configured for that sender and if the authenticated domains align with your From: domain. Often the fix is to add the sender to your SPF record, enable DKIM signing, or adjust domains so that at least one of SPF or DKIM aligns. After you change settings, monitor DMARC reports over the next few days to confirm the pass rate for that source improves before tightening your policy further.&#8221;<br \/>\n    },<br \/>\n    {<br \/>\n      &#8220;question&#8221;: &#8220;Where should I host DMARC and other email-related DNS records?&#8221;,<br \/>\n      &#8220;answer&#8221;: &#8220;DMARC, SPF and DKIM records should be published wherever your domain\u2019s authoritative DNS is hosted. If your nameservers are at dchost.com, you can manage all TXT records directly in our DNS panel or through your hosting control panel (such as cPanel or DirectAdmin). If you run your own DNS on a VPS, dedicated or colocated server, make sure that zone is truly authoritative and that changes propagate correctly. The key is to avoid split or outdated zones; there should be a single, well\u2011managed place where your DMARC record lives and from which recipients query your domain\u2019s policy.&#8221;<br \/>\n    }<br \/>\n  ]<br \/>\n}<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>{ &#8220;title&#8221;: &#8220;How to Read DMARC Reports and Move Safely from None to Reject&#8221;, &#8220;content&#8221;: &#8220; DMARC is one of those DNS records that many teams add once and then ignore, until a partner complains their invoices are going to spam or your brand shows up in a phishing campaign. The power of DMARC is [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4209,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4208","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4208","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4208"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4208\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4209"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4208"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4208"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4208"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}