DMARC fails when neither SPF nor DKIM passes for a domain that matches the one in your From address. A message can pass SPF and pass DKIM and still fail DMARC, because each of them passed for somebody else's domain.
Read the header first
Open the headers of a failed message on the receiving side and find Authentication-Results. A typical failure:
Authentication-Results: mx.google.com;
dkim=pass header.i=@sendgrid.net;
spf=pass smtp.mailfrom=bounces.sendgrid.net;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.comHere DKIM passed for sendgrid.net and SPF passed for bounces.sendgrid.net. The reader sees example.com. Neither result belongs to it, so DMARC fails. p=NONE is the policy the domain published, and dis=NONE is what the receiver did about it: nothing, which is what p=none asks for.
If you see dkim=pass and spf=pass next to dmarc=fail, this is almost always the reason. "SPF and DKIM pass but DMARC fails" means exactly that: the results passed, just not for your domain.
The usual causes
A sending service that signs with its own domain. Newsletter platforms, CRMs, helpdesks and transactional providers sign with their own DKIM key until you set up one for your domain, and use their own bounce address, so SPF passes for them too. The fix is the service's "authenticate your domain" step: a DKIM record (often a CNAME) under your domain, and where the service offers it, a custom return path such as bounce.example.com. One aligned DKIM signature is enough for DMARC to pass.
Amazon SES with the default setup. Mail goes out with an amazonses.com return path, so SPF never aligns. AWS describes two ways out: Easy DKIM, which publishes keys under your domain, or a custom MAIL FROM domain. Either one makes DMARC pass.
Forwarding. A forwarder sends your message from its own server, so SPF fails at the next hop. DKIM survives if the forwarder leaves the message alone. A mailing list that adds a footer or a subject tag breaks DKIM as well, and then nothing aligned is left. Someone else's forwarder is out of your hands, which is why DKIM on every message matters more than SPF here.
A DKIM key that is missing or wrong. The service is set up, but the record was deleted, never published, or published under a different selector. The DKIM checker shows whether the key for a selector is there and parses.
Strict alignment. With adkim=s or aspf=s in the record, a signature from mail.example.com no longer counts for example.com. Relaxed alignment, the default, is what most setups need.
"DNS Authentication: DMARC Fail" in Mimecast
Mimecast puts this line on inbound messages that failed DMARC, often with "Policies Triggered" above it, and what happens to the message then is up to the recipient organisation's policies. If you are the sender, it is the same failure as above with a different label, and the fix is on your side: align DKIM or SPF with your From domain. If you are the recipient's administrator, the message really did fail, and a bypass for that sender lets its spoofs through along with its real mail.
How the test reports it
The DMARC check says "DMARC does not pass" and leaves the domain names to the two alignment checks next to it. Those print the domains side by side: "DKIM signs for sendgrid.net but the From header says example.com", or the bounce address next to the From domain for SPF. Whichever line names a domain you do not recognise points at the service to fix.