Domains
You can only send from a domain you have proven you control. This is not our rule — it is how email works. Without it, anyone could send as you.
Requires the domains scope, or do it in your workspace under Domains, where no API key is needed.
Add a domain
curl https://api.hamanimail.com/v1/domains \
-H "Authorization: Bearer hme_yourkeyid_yoursecret" \
-H "Content-Type: application/json" \
-d '{ "domain": "yourbusiness.com.au" }'The response lists the DNS records to publish.
| Method | Path | Purpose |
|---|---|---|
POST | /v1/domains | register a domain; returns the records to publish |
GET | /v1/domains/:domain | the domain's current verification status |
POST | /v1/domains/:domain/recheck | read your DNS now and confirm |
POST | /v1/domains/:domain/reset | start the domain's verification again |
What each record does
| Record | Type | Why it exists |
|---|---|---|
| DKIM | three CNAMEs | signs every message cryptographically so the receiver can prove it really came from you and was not altered. This is the one that actually verifies your domain. |
| SPF | TXT | lists who is allowed to send for your domain. |
| DMARC | TXT | tells receivers what to do when a message fails the checks above, and where to send reports. |
| Bounce / MAIL FROM | MX + TXT on a subdomain | gives bounces somewhere to go that belongs to your domain, which aligns your mail and improves delivery. |
| MX on the domain itself | MX | optional, and only if you want us to receive your mail. See the warning below. |
Set the DKIM records to DNS only if your provider offers a proxy toggle (Cloudflare's orange cloud). A proxied CNAME cannot be read as a DKIM record and verification will never complete.
Do not publish the MX unless you mean it
A domain's MX record decides where all of its incoming mail is delivered. Publishing ours replaces your current provider.
If your domain is on Google Workspace or Microsoft 365 today, leave the MX alone. Sending needs the DKIM, SPF, DMARC and bounce records only. Your inbound mail keeps working exactly as it does now.
Publish the MX only when you actually want Hamanimail to receive mail for that domain.
Verifying
Publish the records, then call recheck:
curl -X POST https://api.hamanimail.com/v1/domains/yourbusiness.com.au/recheck \
-H "Authorization: Bearer hme_yourkeyid_yoursecret"DNS changes are not instant. A record has a TTL — the time other servers are allowed to keep the old answer — so a change can take anywhere from a minute to a few hours to be visible everywhere. If recheck says the record is missing and you are certain you published it, wait for the TTL and check again.
When verification will not complete
| What you see | Usual cause |
|---|---|
| DKIM records not found | published at the wrong name — check whether your provider appends the domain automatically, which turns abc._domainkey.yourbusiness.com.au into abc._domainkey.yourbusiness.com.au.yourbusiness.com.au |
| DKIM found but not valid | the record is proxied. Set it to DNS only. |
| Nothing resolves at all | the domain's nameservers are not pointing at the DNS provider you are editing. Records added at a registrar you no longer delegate to have no effect. |
| Verified, then failed later | the record was edited or removed. DKIM is checked continuously, not just once. |
That last row matters: a domain that has verified can fail again if someone changes your DNS. We re-check rather than trusting a one-time pass.