Published DNS records are the beginning of a check, not the end. A green lookup cannot tell you whether the message you care about was actually sent using those records, so compare the records with the identities in a real received message.
Start by writing down the identities, for a message you are authorized to inspect. Record the visible From domain (the author-domain identity DMARC uses for alignment), the envelope sender shown in Return-Path (the domain SPF evaluates, and the bounce route; a bounce or other message sent with an empty envelope sender has no domain here, so SPF evaluates the HELO name instead), the DKIM signature's d= domain and s= selector (the signing domain and the exact selector to query), and the outbound IP with its EHLO hostname (the actual source, and whether its forward and reverse names agree).
Read these from the receiving mailbox's original-message view, along with the Authentication-Results header that the receiving system added. For a message with an empty envelope sender, read the HELO name the receiver authenticated (the smtp.helo property) instead of smtp.mailfrom. An Authentication-Results header copied into a message by its sender is not a trusted receiver result.
Next, query the records for those identities. Use the DNS checker with a domain you control, and supply the actual selector when checking DKIM, because guessing a selector from the domain alone is not reliable. Also inspect the SPF record of the envelope domain (or of the HELO name, when the envelope sender is empty) if it differs from the visible From domain. The commands in the example below use reserved example names and a documentation IP address; replace them only with values you are authorized to check.
SPF authorizes an IP address for the SMTP domain identity; it does not authenticate every visible address. More than one applicable SPF record, a broken include, or an exceeded DNS-lookup limit can each cause a permanent error, so do not add broad authorizations just to make a checker pass. See SPF too many DNS lookups and RFC 7208.
Then compare authentication with alignment. DKIM verifies a signature for its signing domain. DMARC evaluates the visible From domain against an authenticated SPF or DKIM identity under its alignment rules, so a third-party domain can pass authentication while failing alignment with your From domain. See DKIM selector not found, RFC 6376, RFC 7489, and DMARC quarantine versus reject.
Use the observed result to decide what to investigate next. A DKIM record that exists while the message carries no signature points at whether the actual sending path signs, can read the right key, and uses the right selector. A DKIM failure points at a selector or key mismatch, malformed signing, or changes made after signing. An SPF failure points at the actual source IP and the envelope domain's authorization, including the effects of forwarding. SPF or DKIM passing while DMARC fails points at alignment with the visible From domain, including strict versus relaxed policy. If everything passes and the message still lands in spam, look at reputation, recipient expectations, and content: authentication does not guarantee inbox placement.
Keep a small investigation record: the time, the sending route, redacted original headers, the actual source IP, the selector, and the results the receiver authenticated. Record what changed, and repeat a permitted owner-controlled test only through your normal runbook. Do not use someone else's mailbox as a seed, attach credentials to a support request, or change a production DMARC enforcement policy from this checklist alone.
For a PulsePigeon sending domain, the domain status and DNS check surfaces show which authentication records must resolve, and the domain API reference lists the provider-assigned records to compare against what you published.