mail

POST `/v1/mail/services/{mailServiceId}/deliverability`

Publish this domain's mail records.

توثيقِ شناخت

ایک بیرر ٹوکن کے طور پر ایک API کی بھیجیں۔ کی کے پاس mail.manage اجازت ہونی چاہیے؛ اس کے بغیر کی کو 404 کے بجائے 403 کے ساتھ مسترد کر دیا جاتا ہے۔

یہ اینڈ پوائنٹ کوئی آرگنائزیشن آئی ڈی نہیں لیتا۔ آپ کی کلید پہلے ہی اس آرگنائزیشن کی شناخت کرتی ہے جس سے یہ تعلق رکھتی ہے، اور اس کا جواب اسی کے مطابق محدود ہوتا ہے۔

آزمائیں

کوئی بھی چیز جو زاویہ دار قوسین میں ہو اسے اپنی اقدار سے بدلیں، اور کلیدی پلیس ہولڈر کو اپنے ڈیش بورڈ کی کسی کلید سے بدلیں۔

curl -X POST https://api.zinndigital.com/v1/mail/services/{mailServiceId}/deliverability \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{  }'

لاگ ان ہیں؟ آپ کے ڈیش بورڈ میں موجود API کنسول آپ کی حقیقی تنظیم کی آئی ڈی اور آپ کی اپنی کلید خود بخود پُر کر دیتا ہے، اور لائیو API پر درخواست چلاتا ہے تاکہ آپ اصل ردعمل دیکھ سکیں۔ اس اینڈ پوائنٹ کو API کنسول میں کھولیں

تفصیلات

Write the correct SPF, DKIM and DMARC records into the domain's zone. ⛔ Refuses with 422 when the apex MX is somebody else's - that is not a state to confirm past from this screen, because the customer's mail is being delivered today and this button must never be how that stops. When records would be replaced, answers 409 until confirm: true is sent, so a destructive apply is always a deliberate second act (the confirm-gated shape #622 forced on DNS). Requires mail.manage.

پیرامیٹرز

نام	قسم	لازمی	یہ کیا ہے
`mailServiceId (path)`	`Uuid`	ہاں	Email service ID (UUIDv7).

درخواست کا باڈی

نام	قسم	لازمی	یہ کیا ہے
`confirm`	`boolean`	نہیں	Required when `needs_confirmation` is true. Defaults to false so a destructive apply is never a side effect of clicking "fix".

جواب

نام	قسم	لازمی	یہ کیا ہے
`domain`	`string`	ہاں	—
`healthy`	`boolean`	ہاں	All three mechanisms present and ours - nothing to publish.
`spf_ok`	`boolean`	ہاں	—
`dkim_ok`	`boolean`	ہاں	—
`dmarc_ok`	`boolean`	ہاں	—
`fixable`	`boolean`	ہاں	Whether a one-click apply is offered. False over a foreign apex MX or an unreadable zone - the panel shows the reason instead of a button.
`needs_confirmation`	`boolean`	ہاں	True when applying would replace published records, so `confirm` is required.
`existing_apex_mx`	`string[]`	ہاں	—
`foreign_mx`	`string[]`	ہاں	Apex MX targets that are not ours - the reason a fix is refused.
`foreign_spf_includes`	`string[]`	ہاں	—
`would_delete`	`string[]`	ہاں	Records an apply would remove or replace, as `NAME TYPE VALUE`. Listed verbatim rather than counted: a customer must not be able to destroy mail records without seeing which ones…
`zone_unreadable`	`boolean`	ہاں	—
`reason`	`string`	ہاں	Customer-grade English. Never a driver message.
`warnings`	`string[]`	ہاں	—
`live_mx`	`string[]`	ہاں	The domain's MX hosts as PUBLIC DNS answers them right now (W43-09) - not our record of the zone. Empty when the domain publishes no MX, or when it could not be read (see…
`mx_readable`	`boolean`	ہاں	False when the public MX lookup failed. A failed lookup is never read as "action needed".
`mx_ok`	`boolean`	ہاں	Every live MX host is one this preset publishes, and there is at least one.
`action_needed`	`boolean`	ہاں	The customer's OWN DNS must change: we cannot publish to this zone and its live MX does not point where this preset sends mail. The panel then lists `required_records` with copy…
`required_records`	`object[]`	ہاں	The exact records to publish, as our preset would write them into a zone we host.

وہ خرابیان جو یہ اینڈ پوائنٹ واپس کر سکتا ہے

401 · 403 · 404 · 409 · 422 · 429

POST /v1/mail/services/{mailServiceId}/deliverability