A Month-Old Domain With Perfectly Clean Authentication

One mailbox at a regional agricultural commodity processor received a payment notification. The sender's display name was Quickbook, one letter short of the accounting platform it was imitating. The subject line spelled the brand Quicbook, dropping a different letter, and promised payment details.

The body was more careful than the spelling. It cited two reference numbers, QB-INV-4682 and PO-INT-221, an invoice identifier of INV-1049-QuickBooks, and a payment timestamp precise to the minute. It carried a contact address that appeared to belong to the real brand. There were no attachments. There was one button, labelled SEE REMITTANCE DETAILS.

And every authentication check on the message came back clean.

Authentication that was configured, not stolen

This is not the usual version of that sentence. In most fully authenticated phishing cases the clean result comes from a compromised mailbox, where the attacker sends from inside a real account and there is nothing misaligned to catch. That is not what happened here. Nobody's account was taken over. The attacker built the sending infrastructure themselves, correctly, from scratch.

The sending domain was registered roughly a month before the message arrived, through a budget registrar, sitting on parked nameservers with DNSSEC left unsigned. Then it was verified through a commercial email service provider that runs on top of Amazon SES. The outbound hop was a genuine SES host at 54.240.9.5, fronted by the provider's own branded DKIM selector.

From there the header stack writes itself. SPF passed, because the envelope sender used a send. subdomain of the attacker domain and that subdomain's record authorizes the provider's infrastructure. DKIM passed twice, once with a signing identity on the attacker's own domain and once with Amazon SES signing on its own behalf. Both signatures aligned with the domain in the header From, because that domain belonged to the attacker.

Every one of those steps is documented in the provider's getting-started guide. There is no exploit anywhere in this chain, just a credit card, a DNS panel, and an afternoon.

Why the missing DMARC policy is a tell, not a technique

The sending domain carried no DMARC enforcement, and it is tempting to file that as the evasion. Precision matters here, because the opposite is true.

DMARC compares the domain that authenticated against the domain a human sees in the From field. In this message those were the same domain. Had the attacker published p=reject on their month-old domain, DMARC would have passed anyway, arguably looking even stronger to a receiving filter. The absence of a policy bought them nothing in deliverability.

What it does buy is a signal for the defender, if anyone is reading it. Publishing DMARC means committing to receive aggregate reports and maintain alignment over time, and nobody does that for a domain they intend to use once. A month-old registration, parked nameservers, unsigned DNSSEC, proper provider onboarding and no policy add up to a coherent picture of disposable infrastructure, built to send and be abandoned. DMARC management and monitoring matters precisely because it turns that posture into something you can measure rather than something you assume.

The actual bypass sat somewhere DMARC was never designed to look. The impersonated brand's domain never appeared in the From header, so the brand's DMARC record, however strict, was never consulted. All of the impersonation lived in a display string and a misspelling, and no amount of policy tightening on the impersonated side changes that.

One button, two hops, and no sign of the brand

The single call-to-action button did not link to the fake destination directly. It pointed at a click-tracking redirector on v3-velocitx.biz[.]id, an endpoint taking a campaign identifier, a link identifier, and the real destination as a url query parameter. The URL fragment carried the recipient's own address, which is per-mailbox telemetry. The operator would know exactly which target clicked.

The destination was a generic login and control-panel page on a domain registered years earlier and hidden behind registrar privacy protection. No affiliation with the impersonated accounting platform, no branding, no pretext continuity with the email at all.

That gap is worth sitting with, and the redirector is what makes it economical. The lure template never changes, and the destination in the url parameter can be swapped the moment a landing page is taken down. MITRE ATT&CK catalogues the pieces separately as spearphishing via link, acquiring domain infrastructure, and impersonation. Here they were assembled into something a finance team sees a dozen times a week.

The brand contact address in the body was a malformed mailto anchor, broken enough that clicking it would go nowhere. It was there for the eye, not the click, which tells you the message was designed for a skim. The 2024 Verizon Data Breach Investigations Report puts the median time to click a phishing link at 21 seconds and 28 seconds to submit data on the page that follows, so a skim is all the attacker was budgeting for.

See Your Risk: Calculate how many threats your SEG is missing

Nobody caught this one in flight

The delivery path was ordinary: provider outbound, into the recipient's on-premises mail gateway, into an Exchange mailbox. No odd relay, no non-standard port, no content rewriting mid-flight. The message was surfaced retroactively, by a scanback pass rather than a live-time block, and no mitigation action was recorded against the affected mailbox, so it most likely sat in the inbox until the retroactive sweep reached it. Our Adaptive AI, Themis, scored it at 88 percent confidence with an invoice-phishing label and a VIP-recipient flag. That second label is the uncomfortable one. A single mailbox, chosen, belonging to someone with signing authority.

What the header stack cannot answer

Authentication answered the narrow question it was asked, twice and cryptographically. It was never asked how old the domain was, whether the display name bore any relationship to it, or whether this sender had ever corresponded with this organization before. Those three questions resolve the message in seconds and none of them live in the header stack. As NIST's definition of phishing frames it, the mechanism is deception of a person, and nothing in these headers was deceptive. Grading the sender and the destination behaviorally, the premise behind credential harvesting protection, is what closes the gap, and CISA's phishing guidance makes the same argument from the process side.

Indicators of Compromise

MITRE ATT&CK mapping

See you next time

A clean SPF and DKIM result on a domain nobody had ever seen before is not a trust signal. It is a receipt for a DNS configuration. The attacker in this case did not defeat authentication, evade it, or steal it. They read the documentation and set it up, the same way any legitimate sender would, and then let the display name do the lying.