A DMARC report can look alarming when it contains failed checks and unfamiliar sending addresses. Those results deserve attention, but they do not all mean that an attacker has compromised the business. Some failures arise from legitimate services configured incorrectly, forwarding behaviour or a mismatch between authenticated domains and the domain customers see in the From address.
The useful task is to classify the sources, understand the authentication results and investigate the business impact. Treat the report as evidence to work through, not as a list of DNS changes to make automatically. A careful review can improve domain protection while avoiding disruption to legitimate invoices, enquiries and customer messages.
Understand what an aggregate report can tell you
Aggregate DMARC reports summarise observations made by participating receiving systems over a reporting period. They commonly group messages by source and authentication results in XML records. The email authentication and DMARC guide explains how to review those observations alongside the actual sending systems.
Begin with the reporting organisation, domain, date range and message counts. Check which period the report covers before comparing it with a recent change. A report received today may describe messages processed earlier.
The report is not a complete record of every message the business sent. It also does not provide a complete account of inbox placement, customer engagement or whether a recipient read an email. Use sending-platform logs and delivery information for those questions.
Keep the raw report or a reliable reference to it when investigating a problem. A dashboard's summary is useful, but the underlying record may be needed to understand an unexpected result or discuss it with the sending provider.
Separate authentication from alignment
SPF and DKIM assess different aspects of email authentication. DMARC also considers whether the authenticated domain aligns with the domain shown in the message's From header. A simple pass label for SPF or DKIM does not, on its own, establish that the message passes DMARC for your domain.
For DMARC, the visible From domain must align with a relevant authenticated domain under the applicable policy. The exact comparison depends on the alignment mode. Ask the technical owner to check the actual domains rather than relying solely on a dashboard's colour. Our SPF, DKIM and DMARC guide explains the relationship between authentication and alignment.
For example, a legitimate marketing platform may authenticate mail using its own domain while the visible From address uses your business domain. Authentication can succeed for the platform's domain while failing to provide the required alignment for yours. The remedy is usually to review the supported domain-authentication configuration with that provider.
A message can pass DMARC through aligned DKIM even where SPF does not provide an aligned pass. Interpret the mechanisms together. Avoid describing every SPF failure as a DMARC failure or every authenticated message as evidence of authorised business activity.
Build an inventory of legitimate sending services
List the systems that send email using your domain. Include ordinary staff email, website forms, CRM messages, invoices, booking confirmations, newsletters and support tools. Ask each business owner which service is used and who maintains its configuration.
For every source, record its purpose, sending domain, provider account, authentication arrangement and responsible person. Include services used only occasionally, such as annual renewal reminders or campaign platforms. A short observation period may not capture every legitimate sender.
Compare the inventory with the report. Mark sources as recognised and expected, recognised but requiring investigation, or unknown. These are working categories, not final conclusions. An unfamiliar source may belong to a legitimate service that another team introduced.
Do not authorise a source merely because its IP address belongs to a well-known provider. Large platforms serve many customers, and shared infrastructure is not proof that a particular message was sent with your permission.
Look at patterns rather than isolated red rows
Group observations by sender, date range and result. Ask whether a failure is consistent across a legitimate platform or limited to a small subset of messages. Compare the pattern with deployment dates, provider changes and campaign activity.
Look at volume as context, while recognising that a low-volume source can still be important. A few failed booking confirmations may affect real customers even when the overall pass rate appears healthy. Conversely, a large set of obvious unauthorised attempts does not necessarily indicate that staff email is misconfigured.
Investigate changes in both directions. A new source may need attention, but an expected source disappearing from reports can also deserve a check. Determine whether the business stopped using it, reporting changed or mail is no longer being sent as expected.
Use source-level DMARC views to investigate which service sent a group of messages. Whichever reporting tool you use, retain enough detail to connect a summary with the responsible system. Our DMARC report review guide provides the related checks.
Recognise forwarding and message modification as separate cases
Forwarding can change the server delivering a message, which affects how SPF is evaluated. DKIM may survive forwarding when the signed content remains intact, but modifications can affect it. Mailing lists and other intermediaries can therefore create results that differ from direct delivery.
If a recognised message fails after an indirect route, obtain a representative message and its headers through the appropriate authorised process. Compare the route, authenticated domains and changes made in transit. Do not assume that adding the forwarding server to your SPF record is the right answer.
Separate these cases from failures on mail sent directly by your own platform. A direct sending service with missing domain authentication needs a different investigation from a customer forwarding a received message through another system.
Use provider guidance for the specific arrangement. General explanations help frame the question, but the technical owner should confirm the mechanism before changing DNS or enforcement settings.
Check disposition without treating it as inbox placement
Reports may show a disposition associated with the receiving system's handling of the message. Read that alongside the published policy and any reported exceptions. A result labelled none should not be interpreted as a guarantee that the message appeared in the recipient's inbox.
Similarly, a DMARC pass does not prove that an email is wanted, safe in every respect or free from other delivery problems. Reputation, content, recipient preferences and other controls can affect handling. Domain authentication answers a narrower set of questions.
If customers report missing messages, inspect the sending system's logs and appropriate delivery evidence as well as DMARC results. Check whether the message was generated, accepted for sending and addressed correctly. An operational failure can occur before authentication becomes relevant.
Make configuration changes from a documented diagnosis
For a legitimate service failing alignment, confirm the provider's supported setup and the business's current DNS records. Record the proposed change, affected service and test plan. Avoid copying an include statement or DKIM record from a different account simply because it appears in an online example.
Do not expand authorised sending sources to remove warnings from a dashboard. Every added source should correspond to a known business requirement and a verified configuration. Keep a record of removed services too, so that obsolete permissions do not accumulate.
Before changing enforcement, check representative messages from all important sending services and agree how failures will be detected. A stricter policy without a verified inventory can affect legitimate customer communications. Equally, reporting alone is not a complete protection strategy. Make the decision with the person responsible for email security and operations.
After a change, verify the actual DNS state, send controlled test messages and review subsequent evidence. Use the relevant reporting periods when interpreting results. Keep the previous configuration documented so that incident handling does not depend on memory.
Turn the review into a manageable operating routine
Assign an owner to review recurring failures and new sources. Define how issues reach the person responsible for a sending tool, and what constitutes an urgent operational problem. A report mailbox that nobody reads provides little value.
Review email authentication when introducing a new business tool, changing hosting or replacing a marketing platform. Include the sender inventory in the handover. Website forms and transactional messages should receive the same attention as ordinary staff email.
Giraffe Digital's digital strategy service considers how hosting, domains, email and business tools support the customer journey. A thoughtful DMARC review fits that wider view: identify the source, distinguish authentication from alignment, verify the business purpose and make a tested change. The aim is reliable communication and clear domain control, supported by evidence rather than alarm.
